Building an Effective Continuous Integration and Delivery Process

Frequent delivery of new features reduces financial risk by providing quick feedback that enables adapting your strategy before spending too much time and money on something. While using the appropriate technology choices is important for delivering a high quality product that is maintainable and scalable, the ability to support continuous integration and deployment is based more on your delivery processes.

To continuously deliver high-quality features to users, two elements are critical: accurately defining the work and having automated processes to verify and deploy changes.

Before starting work on a new story, you must accurately define it by creating a ticket that includes all the necessary information to complete the work as envisioned by the author(s). While doing this correctly does increase lead time, it minimises technical risk that arises from missed or unexpected requirements, or foreseeable technical limitations, and will feed the requirements for automated testing.

While all Git strategies can support continuous integration, trunk based development with short lived feature branches allows you to employ automated change verification while maintaining stability in the primary branch. Feature flags can be used in place of long lived feature branches to control when users get access to features. When a ticket is code complete, code should be peer reviewed and automated build checks should be run before changes are merged to trunk. At the very least the pull request build pipeline should perform code linting to eliminate the need to review code conforms to project conventions, and unit tests should be run to ensure all contracts are being conformed to, as well as integration tests that align to the story’s acceptance criteria. The automated test suite will make manually testing acceptance criteria redundant, however there is always value in exploratory testing.

Pure continuous deployment means deploying your changes on every commit to trunk. By running automated tests on pull requests, code should be stable by the time it is merged and manual regression testing should be unnecessary, however for backend and web projects blue-green deployment can be used to enable a quick rollback in case of any issues. Due to the nature of store reviews and slow rollouts, as well as to avoid spamming users, deploying on all commits to trunk is often impractical for mobile projects. Instead, if your build pipeline supports it, you should use build promotion to deploy to users, bonus points if it allows setting the version number and release notes at that time, otherwise you will need to use release branches to achieve a similar effect. Regardless of platform, the entire deployment process should be automated and require no manual intervention. Change management shouldn’t be required for a deployment, as it should have been completed before the story was deemed ready for development.

While the practices outlined in this article provide a robust framework for achieving effective continuous integration and deployment, it's important to acknowledge that not all elements may apply to all projects. However, by following these guidelines and tailoring them to the specific needs of your project, you can achieve greater stability, scalability, and agility in your product development. Accurately defining work, using trunk-based development, employing automated build and testing pipelines, and automating the deployment process with no manual intervention are all key practices that can help you achieve your goals. By implementing these practices, you can continuously deliver high-quality features to your users and respond quickly to feedback, ultimately helping you stay competitive in the market.