A Complete Guide to Mastering Environments in Your GitLab CI/CD Pipeline

Chanuka Dinuwan
Stackademic
Published in
4 min readDec 31, 2023

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.

  1. 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:

  1. 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:

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

--

--

Published in Stackademic

Stackademic is a learning hub for programmers, devs, coders, and engineers. Our goal is to democratize free coding education for the world.

Written by Chanuka Dinuwan

Software Engineer | Cloud | DS & AI Enthusiast

No responses yet

Write a response