Stafini
BlogFlashcardsProjectsResume

DevOps with GitLab CI/CD - Deployment Environments

What is Deployment Environment ?

The different types of environment

Environments in software development, including Development, Testing, Staging, and Production, serve distinct purposes:

  • Development Environment: For coding and initial testing.
  • Testing Environment: Conducts various testing types.
  • Staging Environment: Pre-production validation.
  • Production Environment: Live environment for end-users.

For the sake of demonstration, we will only setup additional staging environment, this post is a continuity of Continuous Deployment with AWS assumming you've already set up a production env.

Create S3 bucket for staging

Repeat the same step from previous post about creating and setting to host web application

  • Name it whatever you want, best practice to add env suffix to the bucket
  • Change Static website hosting to enabled it
  • Turn off Block all public access
  • Add Bucket policy, same as production bucket, just change Resource ARN

GitLab environment and variables

GitLab's Environment feature allows you to define and manage deployment environments (e.g., development, staging, production). It integrates with CI/CD pipelines, tracks deployment history, supports manual and automatic deployments, and provides visibility into the deployment status of your code.

On the left sidebar, select Operate > Environments. The environments are displayed. Let's create 2 environment for staging and production, they will come in handy when we update CI/CD configuration

Select Settings > CI/CD > Variables from left sidebar, we need to make some changes

Edit current AWS_S3_BUCKET, change environment to production

Add another one for staging and we're done here

Update CI/CD configuration

Now we're ready for multiple environment deployment, let's update the configuration file

stages:
  - .prev
  - deploy-staging
  - deploy-prod

test and build app:
  image: node:18-alpine
  stage: .prev
  script:
    - yarn install
    - yarn lint
    - yarn coverage
    - yarn build
  artifacts:
    paths:
      - dist

.deploy:
  image: 
    name: amazon/aws-cli:2.14.5
    entrypoint: [""]
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
  script:
    - aws s3 sync dist s3://$AWS_S3_BUCKET --delete

deploy staging:
  stage: deploy-staging
  environment: staging
  extends: .deploy

deploy production:
  stage: deploy-prod
  environment: production
  extends: .deploy

Noted

  • We're applying extends syntax to simplify the configuration file as a best practice, should we not some config like: image, rules, script will be duplicated

Continuous Deployment vs Continuous Delivery

You may notice that our deployment pipeline runs in a straight way, as soon as staging deployment is success, production deployment will fire off. What we have been doing is called Continuous Deployment, by fully automates deployment after passing tests, reducing manual intervention, but what if we want to check something before we decide to deploy to production, automates preparation but needs manual approval for deployment. Fortunately that is very easy to archive

deploy staging:
  stage: deploy-staging
  environment: staging
  when: manual
  extends: .deploy

deploy production:
  stage: deploy-prod
  environment: production
  when: manual
  extends: .deploy

Just add when: manual one liner to each deploy job, commit and check pipeline again to see how it goes

A play button shows next to each job now, we can deploy manully whenever we need thus archiving Continuous Delivery

Resource

Happy Coding 🍺🍺🍺 !!!