Speeding up deployment to production (CI/CD with TBD)
CI/CD is of fundamental importance to the success of a project getting out to the market as quickly and efficiently as possible. This article will outline what is CI/CD with TBD, why use it, and how to measure its effectiveness.
Continuous Integration (CI) allows your team to continuously integrate code that is in a shared repository. Continuous Delivery (CD) continuously delivers the code to production from your team's repository. CI/CD can help you get your product to the market by creating a quick and effective process. This enables your team to release features and bug fixes to users more regularly.
Continuous Deployment also exists and this goes a step further than Continuous Delivery. It entails every change that passes successfully through your pipeline going to production. No human interaction is required and if any of the stages fail then the deployment is halted.
Trunk Based Deployment (TBD) is a development model where developers commit into a single branch, usually named master or trunk.
Short-lived feature branches can also be created and once the code builds and all tests pass, it’s merged to master. By doing this merge conflicts that are complex to resolve can be prevented and the development can be truly continuous.
There is a range of benefits that come with adopting Trunk-Based Development that are deserving of an article of its own. Below a few are mentioned.
When developers want to refactor code such as the code design, renaming files, moving classes; this often is strayed away from due to the likelihood of merge conflicts occurring. Therefore doing it directly on the master would be more encouraging to developers in the team to conduct refactoring.
When development is being done on branches the other team members normally don’t have clear visibility of what is being worked on. It only becomes visible when they are merged to master. If the development is done on master it is much easier for other team members to stay in sync.
Often the code review is only done once a pull request is opened to merge into master. At this stage any major changes could mean a lot of re-work. Committing regularly into master allows other developers to notice any issues sooner and give feedback.
Why use CI/CD?
Continuous Integration / Continuous Development (CI/CD) will play a major role in Trunk-Based development being utilized with minimal hindrance as possible.
Below is an example of a CI/CD flow:
Depicted is an illustration of a flow where a developer pushes changes to a code repository. Jenkins (a CI/CD tool) takes the code and performs the CI/CD process to test, scan, package, and deploy. The tools here are used as an example but can be interchangeable depending on preferences, project requirements and application language.
As shown above the CI/CD process consists of multiple stages. Each provides benefits to the team whether it be from a preventive failure standpoint or providing conveniency. A few of the benefits are outlined below:
This ensures the commit hasn’t prevented other developers from building the project
The newly committed code should not have broken existing features causing them to behave unexpectedly for other developers.
Check the newly committed code has sufficient coverage by test cases to help ensure no aspect goes overlooked.
No major vulnerabilities, bugs or technical debt have been added to the repo.
Checking the Style
A team agreed specification for code style has been adhered to, for example open curly brackets on the same line as statements not on the next line.
Before CI/CD is implemented within the team, a few metrics should be noted down. This will help in measuring the success of CI/CD being adopted within the teams workflow. After CI/CD adoption these can be compared to see the improvements made, plus used for continuing fine-tuning of the pipeline going forward.
Time to production.
Once an item meets the Definition of Ready (DoR) then the timer starts on getting the item into production.
Scanning the code with tools such as sonarqube helps raise issues not only in code vulnerabilities but also the cleanliness of the code such as duplication.
The number of bugs released into production should be reduced. This is by having the CI/CD pipeline that runs the tests and checks coverage on new code. If these stages don’t pass then the pipeline will be halted.
Time the pipeline is broken.
A broken build left unresolved can hold up the CI/CD pipeline and delay other team members.
Downtime during deployment.
Having downtime can result in lost revenue therefore automating the process can greatly reduce the chance of failure.
Defect resolution time.
When a bug is raised the time to fix it and promoted to production should be minimal.
Regression test duration.
Regression tests should be run prior to any deployment to help reduce failure. Trying to shorten this task as much as possible will help the team get feedback earlier, fix any issues and re-run.
CI/CD is of fundamental importance to the success of a project getting out to the market as quickly and efficiently as possible. As outlined in this article there are a multitude of benefits from speeding up the development team to mitigating errors occurring. Helping the team maintain the quality of the code also allows them to get their development tasks done faster and work on building features and not tedious or repetitive tasks.
Good article for a overall concept of CI/CD