CI/CD
“Releasing software is too often an art; it should be an engineering discipline.”
― David Farley, Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
What is CI/CD?
CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment.
Continuous integration (CI) is integrating code into a code repository and then running tests automatically, quickly, and frequently. While continuous delivery or continuous deployment (CD) is a practice that is carried out after the CI process is complete and all code has been successfully integrated, so that applications can be built and released automatically. This CI/CD pipeline is often found in software development. Continuous Integration, Continuous Delivery, and Continuous Deployment are phases in the CI/CD pipeline that are the liaison between the development team and the operational team which will be carried out continuously and automatically to get reliable and bug-free software.
Benefits of Using CI/CD
- Obtain faster feedback
Responses or errors are obtained faster because the code is tested simultaneously using CI tools so that the software development process can run in a balanced way. This will help the development team get feedback as quickly as possible. - Detect bug faster
Because we use automatic testing, the bug will be detected by the CI tool so developers will easily find the bug - Speed up release process
The continuous process of code being combined and applied to the product makes the release process of an application faster - Lower Cost
The process of combining code and deploying it is automated by CI/CD, so developers can focus on other things to do and also avoid the cost of fixing errors if something goes wrong in integration or deployment.
CI/CD Tools
- GitLab CI/CD
- Jenkins
- Azure DevOps
- AWS Codebuild
Example of CI/CD in my group project
In developing our project as a group, we use GitLab as a repository for our code and GitLab CI/CD for our CI/CD tools. To use GitLab CI/CD, the next step we need is to configure CI/CD in a file called .gitlab-ci.yml. In this file, we can define the scripts we will use, the configuration files or templates we want to use, dependencies and caches, the commands we want to execute in sequence/parallel, the deployment locations, and configurations that can be triggered automatically or manually. But, I’m using only some of it. In this case, I want to give an example of a CI/CD for a django python application that I want to deploy to heroku.
Stages
Stages are components that determine when a job can be done. In this project, I have 3 stages which consist of the first stage (test) which is testing the application code that I created, the second stage (sonar) is integration with quality assurance software, namely SonarQube, and the last stage is deploy. Based on the understanding of the previous stage, I can give an example that the deployment process of an application can be started if the stage test and sonar are successfully carried out.
- Test
The picture above is the configuration that I use when I want to test in Django application. Here are some explanations of the configuration I showed:
- Image is the name of the Docker image the Docker executor uses to run CI/CD jobs. In this case, we are using python with 3.7.3 version.
- Stage defines where this work will be done which is test
- Before script consists of commands to be executed before the script is executed. In this case, we are installing for some required dependencies like Linux signing key, libraries our app needs in requirements.txt, make migrations to generate SQL commands, migrate to execute SQL commands, download/update the newest versions of packages and the dependencies, collecting static files in Django app and run the server.
- When defines situation that triggers the job will run which is when the previous job was successful
- Script consist of shell script that is executed by a runner. In this case, we do a test for all the included folders, get the report, and export the report in coverage.xml
- Artifacts consist of files and directories to attach to a job on success.
For more information about testing in Django Rest Framework Application, you can access here.
- SonarQube
- Image contains sonarsource/sonar-scanner-cli:4.6 with entrypoint [“”]
- Stage which is sonar
- Script contains configuration of SonarQube. If you need more information about SonarQube, you can read by opening this link.
- Except which is a keyword to control when job is not executed. In this case, I will not run sonar stage in branch development and master.
- Deploy
- Image contains ruby with version 2.7
- Stage which is deploy
- Before running the script, it should install dpl using gem and getting a content from cli assets heroku about install ubuntu
- Run the script and import variables that we need which are heroku app name and heroku API key.
- Environment which is the name of an environment to which the job deploys with name production and the url is a variable, heroku app host.
- Only master will run only in master branch or only staging will run only in staging.
This is the example of using variable in GitLab CI/CD:
You can go to settings -> CI/CD -> Variables. Then you need to fill in the variables that you need there. For example:
The following is an example if all stages are executed successfully until they are deployed:
That is a brief explanation and guide about CI/CD based on my experience. The sources I use will be listed below. Hopefully this article is useful for all of us. Thank you for reading!
References