Deployment and CI/CD
In order to release your product to the general public, you would need to deploy it. Nowadays, deployment can be done automatically instead of manually, this process is called continuous delivery, or CD for short.
You could also automate all processes prior to deployment, such as running tests automatically. This process is called continuous integration, or CI for short.
Hence the act of automatically building, testing, and deploying can be shortened to CI/CD, or continuous integration and delivery. Let’s discuss these terms one by one.
Deployment
Deployment is the act of making the software you created available for use. For example, when developing a website, you deploy your product to the worldwide web.
Deployment can be done manually, or automatically with continuous delivery. Manual deployment is not only more difficult, it’s also much more prone to errors.
Continuous Integration
Continuous Integration or CI is a method of continuously integrating new code into a certain repository. The integration would be verified by following a build and/or test sequence to validate the newly added code.
Continuous integration is not only useful to automate mundane tasks of building and testing, but it’s also handy to prevent and reduce bugs.
Also, since the process of CI is transparent, you and your team can clearly see when, where, why, and what has failed in your test and build sequence, and can then quickly correct it.
Continuous Delivery
Continuous delivery is the process of getting all new changes to production. In other words, it’s the act of releasing all changes to the user in a safe and maintainable manner.
Continuous delivery makes the deployment process much faster and easier. By automating deployment, developers can focus on other more pressing matters, such as testing and refactoring their app to increase its overall quality.
Applying CI/CD
To apply CI/CD to your project, you first need to have a central repository to store your code. You can use git along with GitLab or GitHub to do this. Every time you implement something new to your code, you need to commit the change to that repository.
Also, you need to make automated tests for your code. It’s also recommended to use TDD to ensure that your code is of top-notch quality.
You then need to make a CI/CD script to run on your repository. On Gitlab, the script file needs to be called .gitlab-ci.yml. The file would be automatically run every time there is a new commit to the repository. On GitHub, you can use Github actions.
The CI/CD script can be used to make a linter check, build the project, run tests, check for security issues, deployment, and so on.
CI/CD Example
Here’s a Gitlab CI script for a react project:
As can be seen on the top of the file, there are four stages in total in the script, that being lint, test, sonar_scanner_test, and deploy.
The lint stage checks for bugs, errors, or semantic and stylistic smells. Then the test stage runs automatic tests for the project, and sonar_scanner_test uses sonarqube tool to measure the project. Finally, the deploy stage deploys the application.
We can also see that there are two jobs for deployment, that being staging and production. The staging job is for the staging branch, while on the other hand the production job is for deployment on the master branch.
Pipeline
Whenever we make a commit to Gitlab, this CI script will run the jobs in a pipeline. Here’s an example of a commit pipeline:
This pipeline has four stages. Every stage that succeeds will have a green checkmark. Every stage that doesn’t would have a red cross. If a required stage fails, then the entire pipeline would fail as well, just like in the image above.
Remembering the four stages mentioned before, we can see the benefit of applying CI/CD to our project clearly.
Imagine the hassle of repeating this process every single time for every change we make to the project. By using CI/CD, we can automatize all our tasks from building and testing the app, all the way up to deployment.
Conclusion
Developers need to worry about many things when working on their code. These include increasing code coverage, implementing features, creating tests, and so on.
With the existence of CI/CD, we can at least reduce the burden somewhat on developers, as deployment, testing, and building can be automated. Additionally, we can also prevent and reduce the number of bugs on our code by using a fixed CI/CD script.
References:
