Deployment with CI/CD
In order for the public to use our product, it needs to be deployed to platforms. Software deployment can be done automatically, by the help of CI/CD. The term CI/CD should be familiar when you’re developing software. CI stands for Continuous Integration, but CD is often confused as either Continuous Delivery or Continuous Deployment.
Continuous Integration
Developers often merge changes to a central repository. However, the changes need to be validated. How? CI verifies the integration by creating a build and automate tests against the build. CI automation test helps ensure the application is not broken whenever there are new commits. Some benefits of CI are:
- Early bug detection: if there’s an error at local that has not been checked yet, the build will fail early.
- Reduces bug count: easier to detect and fix bugs.
- Automating the process: provides a clear path for a successful continuous delivery process.
- The process becomes transparent: developers know where and when a test fails and what’s causing the error.
- Cost-effective process: manual testing time is reduced.
Continuous Delivery
Continuous delivery is an extension of continuous integration. This is where all of our changes are delivered to production in a safe, quick and sustainable manner. On top of automated testing, CD supports an automated release process. Continuous delivery helps us schedule the time to deliver the changes. But, to make the most of its benefits, it is better to release as soon as possible just in case a problem occurred on deployment. Continuous delivery helps our deployment faster and easier. Since the deployment is automated, developers can relax a bit because the amount of rework can be reduced.
Continuous Deployment
The main difference between continuous delivery and continuous deployment is that there’s no human intervention in continuous deployment. The production code is deployed automatically without any interaction from the developers, an example is code review.
CI/CD Implementation
Our group implements CI/CD with the help of Gitlab’s CI/CD. We have 3 separated repositories for our backend, website and mobile application. All of these repositories implement CI/CD. Every time there are new changes to our code, we commit the changes to the repositories. We also automate our tests with the help of CI/CD.
Most importantly, a CI/CD script is needed. We call this script the .gitlab-ci.yml file. If we push a commit to our remote repository, this file will be executed.
Here’s an example of the gitlab-ci.yml file for our mobile app project:
Our CI/CD script consist of several stages. For commits pushed to features branch, it will only execute lint, test and sonarqube. Commits for staging branch will execute those 3 stages too, followed by build and deployment to PlayStore internal. For commits in the master branch, it executes the same stages as staging, but it builds the production app bundle and will be deployed to PlayStore alpha.
The lint stage checks for code semantics and error. The test stage will run the automated tests. Sonarqube will analyze our code by looking for bugs, code smells and measures our code quality. The build stage will build our application and finally the deploy stage will deploy the application to the intended environment.
We can see the jobs of each commit on pipelines. Here’s an example of a failed pipeline:
This pipeline fails on the lint stage. This is one of the proof that CI/CD helps us detect bugs early. Next following stages won’t be executed if the previous stage fails.
Here’s an example of a successful pipeline:
Since this is the staging branch the stages that are successfully executed are lint, test, sonarqube, build and deploy.
CI/CD helps our deployment process be more efficient. The automated test, and stages on pipelines ensure our applications are working fine before deployed to their respective environment.
