CI/CD Pipelines
Introduction¶
This documentation outlines the Continuous Integration and Continuous Deployment (CI/CD) process for the software development workflow at GREPSR The process is designed to ensure efficient and automated building, testing, and deployment of code changes, while maintaining version control and quality assurance. This documentation covers the steps involved in the CI/CD process, including code linting, code scanning, image building, deployment on Kubernetes, and versioning.
Overview¶
The CI/CD process at GREPSR follows these key steps:
1. Code Linting and Code Scan
2. Continuous Integration (CI) with Bitbucket Pipelines
3. Image Building
4. Deployment on Kubernetes
5. Rollback Mechanism
6. Versioning
Let's explore each step in detail:
1. Code Linting and Code Scan¶
When a developer pushes their code and bumps the version, the CI/CD process starts with code linting and code scanning. This step ensures code quality and security. The code scan using Snyk is performed periodically (e.g., every week) to identify any vulnerabilities in the codebase
2. Continuous Integration (CI) with Bitbucket Pipelines¶
After the code linting and code scan, the CI process begins using Bitbucket Pipelines. Bitbucket Pipelines is configured to automatically trigger the CI process when changes are pushed to the repository. The CI pipeline defines a series of steps and actions that need to be executed for each code change.
Within the CI pipeline, an image is built using the defined Bitbucket Pipelines configuration. This image can be a container image or any other artifact required for deployment. The image is built based on the code changes made in the repository
3. Image Building¶
4. Deployment on Kubernetes¶
Once the image is successfully built, the CI pipeline triggers an automatic deployment on Kubernetes. Kubernetes is a container orchestration platform that manages the deployment, scaling, and management of containerized applications. The deployment process ensures that the latest version of the application is deployed on the Kubernetes cluster.
5. Rollback Mechanism¶
In the event of any errors or failures encountered by the deployed pods, a rollback mechanism is in place. The system automatically reverts to the last known working version of the application. This ensures that the application remains stable and functional, even in the presence of unexpected issues. To achieve this we will have a file with the previous working version and the newly built version. When an error occurs during the build we use this file to revert back to a working version.
6. Versioning¶
Versioning is an essential part of the CI/CD process. The version number helps track and identify different releases of the software. At GREPSR, the versioning follows the "major.minor.patch" format.
- Patch version:
The patch version includes bug fixes, refactors, and hotfixes.
When committing changes to Bitbucket, a patch version should have the following format: Jira ticket, patch type. The Jira ticket can be optional for patches.
- Minor version:
The minor version includes enhancements and new small features. For a minor bump, the commit message should include: Jira ticket, short description of feature.
- Major version:
The major version includes significant features and changes. For a major bump, the commit message should include: Jira ticket, short description of feature.
These commit message formats are mandatory and are checked during the code push to Bitbucket to ensure consistency and traceability.
Conclusion¶
The CI/CD process at GREPSR incorporates code linting, code scanning, continuous integration, image building, Kubernetes deployment, rollback mechanisms, and versioning. This process streamlines the development workflow, ensuring that code changes are thoroughly tested, deployed efficiently, and versions are tracked accurately. By automating these steps, the CI/CD process improves development efficiency, reduces manual errors, and maintains code quality and security throughout the software development lifecycle.