Deployment in GitLab

GitLab is a platform that we use within AI Singapore, it supports Version Control, Issue boards, Wiki pages and Deployment Pipelines. We will talk about how we use GitLab to deploy applications in this article.


What is Deployment?

The process to allow a software or platform to be accessible to the users. This can be done manually or automatically, depending on the tools used. This is usually the last stage of the process, where we have completed coding and testing on our local machines. We want to be able run our application on a server so that our users can access it. We can also deploy test environments to allow for extensive testing of a new system.


What is CI/CD?

This refers to Continuous Integration and Continuous Delivery. We can automate code checks, tests, builds and deployment when there are changes checked into a GitLab repository. 

(Image source : GitLab homepage)

A GitLab Job is triggered when changes are pushed to a GitLab Repository. Depending on how the CI/CD file .gitlab-ci.yml is set up, the GitLab job will build, check and deploy the application. We can set up the file to only deploy from specific git branches (e.g. production or staging).

In most of our in-house applications, the deployment stage of a CI/CD pipeline is similar and reusable. 

Here are some of the benefits of automatic deployment and CI/CD:

  • Developers can focus on the code rather than on the deployment.
  • It is easier for developers to get quick feedback on any small changes they have made, this will make debugging easier.
  • By using CI/CD as part of the development process, we can test out any code and config changes in a testing environment, before rolling this out to the production server. This is especially useful when testing out new features.
  • It is a repeatable and trackable process, with rollback functionality (when turned on).
  • It allows developers to continuously test any config changes. This removes any human error when deploying it manually, such as missing files or environment variables. The environment variables are also stored in Gitlab CI/CD Settings.


The Tools

We use GitLab, Docker, Helm and Skaffold to deploy our applications and services to our Kubernetes clusters.

  • GitLab CI/CD  is integrated into our GitLab Projects, this contains our code and environment variables required to deploy our application.
  • Docker is a type of containerization tool, which allows a developer to package code, dependencies in order to run an application in multiple environments.
  • Skaffold is developed by Google, it allows you to build a pipeline to build, push and deploy your applications using configurations defined in a YAML file.
  • Helm  is an open source project used to manage packages on Kubernetes.

We place the aforementioned .gitlab-ci.yml file in the root directory of the repository. This file defines the stages of our deployment (e.g. Code Checking, Build, Deploy). Within each stage, we can define a list of steps to execute. Refer to the screenshot below.

  • The first stage (code_check) installs the packages, does code linting and builds a docker image.
  • The second stage (deploy_staging) will login to the docker registry and run the skaffold pipeline to deploy the application to our Kubernetes cluster.

In this case, we are deploying an application to our staging environment, we can define multiple environments within .gitlab-ci.yml (e.g. staging and production).

In the deploy_staging, we call the skaffold command.

skaffold run --filename=skaffold.yaml --namespace=your_namespace

Running the command above will execute the pipeline, to build the Docker Image and deploy to Kubernetes (using Helm) with the variables read from GitLab according to what is defined in skaffold.yaml.

An example skaffold.yaml file is shown below.

apiVersion: skaffold/v1
kind: Config
metadata:
  name: application-name
build:
  artifacts:
  - image: docker.io/yourapplicationImage
    docker:
      dockerfile: Dockerfile

deploy:
  helm:
    flags:
      upgrade:
        - --install
    releases:
      - name: yourAppName
        chartPath: yourApp
        namespace: your_namespace
        values: 
          image: docker.io/yourapplicationImage
        setValueTemplates:
          YOUR_VAR : "{{.VARIABLE_NAME}}"

As can be seen, the deployment step uses Helm. In this case, we are deploying a custom application yourApp using Helm charts. The Helm charts contain the configuration details, such as environment variables and the parameters used to spin up the Kubernetes pods (eg: RAM Size, Namespace).

A helm chart consists of a collection of files that define your deployment. We would not touch further into this for this article, that would probably take up another blog post.


Running GitLab CI/CD Pipelines

Once the GitLab CI/CD file is set up correctly, we can run the pipeline through the GitLab interface or by pushing code to the repository.

Here is a screenshot of the GitLab CI/CD Jobs. We can see that there are 2 steps here – code_check and deploy.

We can also look at the detailed logs by clicking on Job IDs.

That was a quick review of the deployment tools and steps within our team and how we use the tools to automate some parts of the process. I hope you have learnt a little bit about the motivation for this work and gained some insight into how we deploy our applications here at AISG.




References