Continuous Integration and Deployment using GitLab
Let’s utilize CI/CD for Software Development!
CI/CD Concepts
On software development that uses continuous method, you continuously build, test, and deploy iterative code changes. This iterative process helps reduce the chance that you develop new code on buggy previous version. By using this method, you will have less human intervention from the development of new code until its deployment.
There are three primary approaches for the continuous method:
- Continuous Integration
- Continuous Delivery
- Continuous Deployment
Continuous Integration
Each change that submitted to an application is built and tested automatically and continuously. Each changes will be test to ensure that the changes are passing all tests, guidelines, and compliance standards that you established for your application.
Continuous Delivery
Each code change that submitted to an application is built, tested, and deployed continuously. However, with continuous delivery, it requires human intervention to manually trigger the deployment.
Continuous Deployment
It is kind of similar with Continuous Delivery. The difference between this approach with Continuous Delivery is that the application will be deployed automatically. So, human intervention isn’t required.
GitLab CI/CD
It is a part of GitLab that can be used for all of the continuous methods. With this, you can test, build, and deploy your software automatically.
Workflow
Common development workflow can be easily integrated with GitLab CI/CD.
At first, you can start by discussing a code implementation in an issue. Then, working on it locally. After that, you can push code changes to your feature branch in a remote repository (hosted in GitLab). The push will trigger CI/CD pipeline for your project. Then, GitLab CI/CD will run automated scripts to build and test your application. While the script is running, you can preview the changes in a ReviewApp. If the implementation works as expected, you can get your code to be reviewed and approved by others. And then, merge the feature branch into the default branch. If something goes wrong after being merged, you can roll back your changes.
Concepts
In this section, I only provide a brief explanation of some concepts in GitLab CI/CD. You can go to this link if you want to learn more about GitLab CI/CD Concepts.
Pipelines are the top-level component of continuous integration, delivery, and deployment. Pipelines contain of Jobs and Stages. Jobs define what to do, while Stages define when to run the jobs.
Variables can be use to control the behavior of obs and pipelines, store values that you want to re-use, and avoid hard-coding values in the .gitlab-ci.yml file.
Environments describe where code is deployed.
Downloadable archive of files and directories from Jobs.
How to make use of GitLab CI/CD (General)
- Create a repository on GitLab.
- Add your application code.
- Add a file with name .gitlab-ci.yml on your project.
- Write build, test, and deployment scripts on .gitlab-ci.yml.
- Push changes into your project’s remote repository.
Example
Here, I’ll explain to you how I make use of GitLab CI/CD to deploy Django Application into Heroku via Docker images. Note that the deployment method in this example is utilizing Heroku’s Container Registry. And, make sure that you already created an application on Heroku that will be used for Docker image deployment.
Let’s take a look on the script below.
As you can see, I’ve structured the pipeline with 3 stages which are build, test, and deploy.
- Build stage
This stage consist of one job, that is Building Dev. In this job, I use kaniko for building docker images and pushing it into Heroku’s Container Registry.
HEROKU_APP_NAME : Your Heroku’s application name
HEROKU_API_KEY : Heroku API token that can be retrieve using Heroku CLI. Check this link.
HEROKU_USER_EMAIL : Your registered email that related with your Heroku’s application.
- Test Stage
This stage only have one job, that is Testing. At this job, I use python 3.8 image for testing the Django Application that I’ve created. At the end of the job, this will export coverage-reports directory that created by the coverage command.
- Deploy Stage
This stage also only consist of one job, that is Staging. At this job, I releasing the images that has been pushed into my Heroku’s container registry.
