It mainly comes down to trust in deploying to productive environments at scale. Teams who want to adopt this model spend a lot of time thinking and developing the right (and complete) test suite before adopting this for production. What is more important is to define a minimal set of essential business features that need to work and codify the tests to give you quick feedback. Even if you start with around 95% test coverage of critical features and behaviors, it is good enough to get things rolling. Once the deployment tooling and a minimal test suite are functional, you can build from there. An immediate benefit that teams get is an understanding that this can work in practice.
However, a lot of success in this area is dictated by your branching strategy.
An effective branching strategy is key
At the heart of a CI/CD implementation lies your code branching strategy. The main goals are to reduce the code-merge friction between several developers, make the new changes visible across the entire team, and increase the process reliability around the release of new software changes.
In continuous deployment, it is strongly recommended to work off the trunk – yourmain branch. Working with feature branches results in all sorts of issues around merge conflicts and stale code. This problem is further exaggerated with weekly or bi-weekly sprint cycles where developers work in isolation, at least until the last few days before the sprint’s closure. As a side note, if you’re interested in knowing why starting the sprints on Wednesdays could be a good idea, I recommend giving this post a read: https://resources.scrumalliance.org/Article/best-day-start-sprint.
When working with trunk branches, the first question teams have is how to avoid unintentional impacts caused by new features. This is where I can recommend adopting feature toggles.
Working with feature toggles
Feature toggles, also sometimes called feature flags, is a technique where new software features can be launched rapidly but safely. They are reflected by software design patterns where some features can be enabled or disabled remotely. This gives teams the flexibility to quickly revert to old workflows without going through the usual deployment cycles. Thisalso allows A/B testing as teams can temporarily enable certain features to study the behaviors of end users and how they are consuming any new functionality.
With this, even untested and incomplete code can be safely, and silently, shipped to production as part of regular deployment cycles. However, it’s important to note that feature flags come with additional complexity in the code, are harder to test, and might sometimes hide actual code running in production. So, overuse should be avoided.
As we wrap up this section, I want to offer a brief word of caution.