A Complete Guide to Mastering Environments in Your GitLab CI/CD Pipeline
Why Are Environments Important?
Imagine that you have coded your ground-breaking app, which has the potential to alter the course of history. But wouldn’t you want to give it a complete test run before releasing it to the public? This is where the role of the environment is relevant. They serve as separate testing environments, simulating the many phases of your application, including development, testing, staging, and production.
Consider them as secluded play areas where you can:
Code updates can be tested and debugged safely without endangering your running application.
Set up variables and settings, such as database connections or API keys, that are unique to each step.
Updates should be released gradually to reduce risk and increase control.
Visualise the history of deployments and monitor performance in various scenarios.
- Manual Environment Creation:
Go to Settings > CI/CD > Environments in your project.
Select “New environment.”
Name it, specify a URL that is optional, and decide whether to use an automatic or manual deployment method.

To create a new environment and set its values:
Initiate environment creation: Locate and click the Add New Environment button.
Configure environment values: Access the Gitlab settings to define the values associated with the newly added environment.

2. Dynamic Environment Creation (via .gitlab-ci.yml
):
Define a job in the deploy stage of your .gitlab-ci.yml
file. After that, you can use this configuration to change the pipeline.
variables:
S3_BUCKET: {S3 bucket name}
image: alpine:latest
stages:
- "build"
- "test"
- "deploy"
render_website:
stage: build
script:
- apk add markdown
- mkdir -p public
- markdown website.md | tee public/index.html
artifacts:
paths:
- "public/index.html"
test_website:
stage: test
script:
- apk add libxml2-utils
- xmllint --html public/index.html
dependencies:
- "render_website"
deploy_website:
stage: deploy
script:
- apk add aws-cli
- apk s3 cp ./public/s3-//$S3_BUCKET/ --recursive
dependencies:
- "render_website"
environment: qa

This GitLab CI/CD pipeline is designed to automate the build, test, and deployment process for a static website. The pipeline consists of three stages: “build,” “test,” and “deploy.” Here’s a summary of each stage:
- Build Stage (
render_website
):
- Installs the
markdown
package. - Creates a “public” directory.
- Converts the content of “website.md” to HTML using the
markdown
command. - Saves the generated HTML as an artifact.
2. Test Stage (test_website
):
- Installs the
libxml2-utils
package. - Uses
xmllint
to validate the HTML structure of the generated "public/index.html" file. - Depends on the successful completion of the “render_website” stage.
3. Deploy Stage (deploy_website
):
- Installs the AWS CLI (
aws-cli
). - Copies the contents of the “public” directory to a specified S3 bucket using the
aws s3 cp
command. - Depends on the successful completion of the “render_website” stage.
- Specifies the deployment environment as “qa.”
The pipeline is intended for deploying the static website to an S3 bucket in a quality assurance (QA) environment. It incorporates dependencies between stages to ensure that each stage is executed successfully before proceeding to the next. The artefacts generated during the build stage are used in subsequent stages, promoting a streamlined and automated CI/CD workflow for web development.
Using the below configuration we can set deployment to manual.
deploy_website:
environment: qa
stage: deploy
script:
- apk add aws-cli
- apk s3 cp ./public/s3-//$S3_BUCKET/ --recursive
dependencies:
- "render_website"
rules:
- when: manual
We can see a manual deployment button in the below picture.

Deployment that happens automatically We can configure it as follows:
deploy_website_staging:
environment: qa
stage: deploy
script:
- apk add aws-cli
- apk s3 cp ./public/s3-//$S3_BUCKET/ --recursive
dependencies:
- "render_website"
rules:
- if: $CI_COMMIT_BRANCH == "main"

rule:
- if: $CI_COMMIT_BRANCH =~ /^feature/
branch name should begin with the feature.
Instead of creating a branch for every change we can set tags.

deploy_website_staging:
environment: qa
stage: deploy
script:
- apk add aws-cli
- apk s3 cp ./public/s3-//$S3_BUCKET/ --recursive
dependencies:
- "render_website"
rules:
- if: $CI_COMMIT_TAG
You can find the rollback button down there. In Action column:

Bonus Tips for Environment Mastery:
Keep an eye on your surroundings: For proactive troubleshooting, keep an eye on their performance and well-being.
Adopt distinct pipelines for every environment to improve control and isolation.
Utilise environment factors and trade secrets: Preserve private data in a controlled and safe manner.
Apply deployment techniques: For safer rollouts, consider canary or blue/green deployments.
Stackademic 🎓
Thank you for reading until the end. Before you go:
- Please consider clapping and following the writer! 👏
- Follow us X | LinkedIn | YouTube | Discord
- Visit our other platforms: In Plain English | CoFeed | Differ
- More content at Stackademic.com