Continuous Integration/Continuous Deployment (CI/CD) and Business
Author: Richard Boroczky
On the surface, Continuous Integration (CI) and Continuous Deployment (CD) sounds wonderful, but there are a lot of things that should be taking place behind the scenes. That's where checks and balances in the Software Development Life Cycle (SDLC) and a good Application Lifecycle Management (ALM) platform come into play, but for now, a basic understanding of what each requires is in order.
Continuous Integration (CI) means that you can have more merges of multiple branches into your code repository's trunk, but there needs to be check points in this process to help ensure that code quality and coding standards are upheld. That is where branch policies come into play giving you the ability to have what we call a gated-check-in. A gated-check-in is where you add policies that must be adhered to before accepting a branch merge into trunk.
At a bare minimum, these branch policies should require a code review by someone besides the person requesting the pull request (PR) and there should be a successful automated build for the requested PR. There are other verification steps that you can add such as requiring success unit test execution for each project in the repository and/or adding ESLint usage when dealing with JavaScript code. Mind you, this is for a simple code repository structure and depending on the projects complexity you can end up with numerous main branches in a repository such as adding new features that you want to keep separated or different versions that still need to be supported for your clients but should never be merged into your main trunk, but that is all for a different blog.
Now that the basic requirement for getting started with CI are understood and that you now know that CI is not just some magical process that occurs when you say its name three times, we can get into the basics of Continuous Deployment (CD) and what it really means!
Continuous Deployment (CD) or as some view it, Continuous Delivery, is just another process that can be automated to make sure certain environments have the latest code deployed to it. However, it is not something you want automated for your customers; you will want to ensure that you only release to them what you deem as production ready. For this reason, Continuous Deployment is not as fast or “continuous” as some may think. Yes, automation is wonderful, and some use cases might exist that would permit CD to your customers, but should you allow it? I believe it is good to have scheduled (such as nightly) deployments to DEV and QA environments, but it is always best to know that the product you are going to deliver to your customers has met the highest quality standards allowed by your business sector; you don't ever want to deliver a bug fix or new feature without ensuring that something else was not broken by the code changes. This is where QA and regression testing shines. Each step of SDLC must be respected and in doing so will help keep your customers coming back!