Deployment, CI/CD, & Software QA
In this article, I will be talking about Deployment, Continuous Integration and Delivery, and Software Quality Assurance.
- Deployment — software deployment includes all the processes required for preparing a software application to run and operate in a specific environment. It involves installation, configuration, testing, and making changes to optimize the performance of the software. Deployment can be carried out manually (just like in our group project, Fleet Tracker) or through automated systems. In Fleet Tracker, we have been using Docker for our deployment process.
- CI— Continuous integration (CI) is a mechanism used by development teams to integrate and validate small changes and check-in code to version control repositories frequently. If the integration process is done with consistency, teams would commit code changes more frequently, thus leading to better collaboration and software quality.
- CD — Continuous Delivery (CD) is an extension of the CI process. It’s the automation of the release process so that new code is deployed to target environments (usually test or staging environments) in a repeatable and automated fashion. CD is also used to describe Continuous Development, which focuses on the automation process to release what is now a fully functional build into production.
- Software QA — Software Quality Assurance is a systematic process to check if a software has been developed according to the requirements set previously. This process is usually done by a QA Tester or a QA Engineer.
How We Implemented This In Our Project:
In HappyFresh Fleet Tracker, we chose to use Docker to help deploy our application. There are three environments that are running in our project: development, staging, and production.
Each environment is run on a separate internal port, and external requests will be redirected to the environments based on their respective subdomain names: “dev.hf-tracker.com, staging.hf-tracker.com, hf-tracker.com).
We have been using Gitlab’s pipeline for the CI/CD. Since Fleet Tracker consists of the front-end and the back-end, there are two different sets of pipelines on our Gitlab, each with their respective related branches.
There are two containers, one for front-end and one for back-end. These containers are pushed into the container registries and deployed when the manual trigger for deployment is executed.
This is our gitlab-ci configuration:
https://gist.github.com/nardienapratama/a3a430da42a6e194e1a8d45909217e4c
As you can see in the snippet above, there are the three stages mentioned previously: build, test, and deploy. This CI is used for both the front-end and the back-end of our project.
There are two Docker container images that we have pushed to Fasilkom’s Image Registry:
As for Software Quality Assurance, we have made unit tests for our handlers in our project and our code coverage has been around 88–92% so far. We have also been meeting with our Product Owners once every two weeks to discuss about whether our development up to that point meets their requirements and whether they want to accept or reject the development.
So that’s all for this article. Hope you found it useful!
Sources:
