Assess CI/CD maturity
At Devbridge, we recognized the value of complete deployment automation and resolved to include continuous deployment as part of our processes and best practices. As a first step, we explicitly took inventory of the build process to pave the way for successful continuous deployment.
The steps documented included:
Submit a build containing code changes.
Execute unit, integration, API, end-to-end UI, and performance tests against the build.
Hold the build in a staging environment while completing (1 week) manual regression testing, all stakeholders to complete UAT, and deployment to production approval.
Shut down the entire system for an update (usually during off business hours).
Perform a database backup.
Manually approve the deployment of the new code into production.
Perform a smoke test.
Restore the production system.
* The steps in bold above are overhead.
After a critical review of the process, Devbridge observed that:
Many significant overhead steps and delays had a direct correspondence with various manual steps in the pipeline.
Typically, code changes were held up for at least a week before reaching customers.
Manual regression testing took an entire day to complete, with the team wasting valuable time waiting for results.
In each sprint, two team members would work during off-hours to deploy the new version of an application to production.
Due to time constraints, hotfixes didn’t get the same level of attention as standard releases. Risks were taken, and quality was lower.
Recognizing that there were opportunities to optimize the pipeline for higher productivity, we began our journey toward continuous deployment.