Continuously adopting Continuous Delivery
So you’re bought in on Continuous Delivery: You’ve studied up, understand why it’s different and how it can benefit your organization. What happens next?
For most organizations, adopting Continuous Delivery does not just happen overnight – and that’s okay. In fact, recognizing that it can be a big transition is an important step to adoption. Because while you might be anxious to start reaping the benefits of this approach, you need to roll it out correctly – including adjusting your processes and warming up your team to those changes – to realize the desired results.
With that in mind, here are a few suggestions for some easy ways to get started with Continuous Delivery.
Get familiar on a personal project
I often recommend starting with Continuous Delivery on a hobby project, like a personal website. This approach is a good way to get familiar with the tooling and processes for Continuous Delivery in a relatively low-risk environment. Your personal website went down briefly? Shucks.
Even though it will be very lightweight in comparison to what your organization will eventually do, it’s helpful to get up to speed and feel comfortable helping the rest of your team adopt the practice.
Introduce a branching strategy
Continuous Delivery and GitOps often go hand in hand. Being able to know what version of source code is running in an environment is increasingly important when shipping frequently. You should have your branching strategy documented and have buy-in from everyone on the team. It is something you’ll want in the future as onboarding materials when you hire more folks to the product delivery team. Everyone on the team should know where to look at the source code for an environment if something goes wrong.
GitOps for staging and production
For early stage companies that are not yet practicing Continuous Delivery in any form, it can be a big process shift to ensure all changes are production ready. We often have teams start off with two branches
next to automate deployments. Pushing or merging code the
next branch will automatically deliver to the staging environment and pushing or merging code to the
main branch will automatically delivery to production. Have your team use
next as a base branch and be able to test in your staging environment. Some common trouble areas in keeping code production ready are adopting features flags, handling datastore migrations, and maintaining backwards compatibility. Document anything that needs extra review and consider using something akin to code owners for any changes that can cause downtime. For instance, code that migrates between database schemas has a special process internally at Spaceship since database locks can sometimes be unexpected.
Starting with a staging environment is especially helpful since it gives everyone a chance to get used to the workflow – pushing updates, soliciting feedback, and making updates before it gets to customers. It also builds trust in your quality assurance practice that bugs will be caught before making it to customers. Once you’ve reached relative, but perhaps not absolute, comfort its time to move on. Once your team feels comfortable with this process, start targeting all of your pull requests to the
main branch instead of
next so they go to production. Changes that still require manually testing can be targeted to next first, then simply PR
main. Using continuous delivery in production may feel daunting at first, but the joy of regular shipping updates will quickly outweigh any anxiety.
Adopting review environments
Finally, there’s still progress to be made even for growth stage companies that are delivering to production via Continuous Delivery. At this stage, the next step is replacing any staging environments that your team might use to manually test any riskier changes with review environments. Review environments are ephemeral environments stood up for the lifecycle of a pull request. It provides a real live environment for teams and especially non-technical stakeholders to be able to review changes to software before they go out.
This approach requires automating the setup of your entire stack to make it ready for testing. In some cases, this can require a lot of changes. Anything that was manually configured for one or two environments now needs to be automated. For instance, if your application integrates with 12 external services and you want 12 review environments, you might have to manually make accounts with each of those vendors and associate them with the appropriate review environment. This is commonly the case with authentication providers – OAuth, SAML, and OpenID connect apps.
Once you have review environments, you can begin to establish better collaboration with the entire product delivery team. It will allow QA to test changes in isolation leading to quicker QA cycles. It will allow the product owner to verify the in-browser user experience. This often is surprisingly different than our mental model of designed experience. It will let designers quickly identify and communicate any visual differences. It even lets developers reviewing source code a chance to use the code that they are reviewing. This step is skipped surprisingly often because of the hassle of shelving your own work to review locally. Establishing collaboration around review environments as a pre-production step will increase your confidence in Continuous Delivery.
Measure your team’s success
Continuous Delivery is a practice. Adoption will improve over time. Make sure at every step of the process you are keeping the pulse of the team and providing adequate training and communication around process changes. These phased approaches to adopting and maturing a Continuous Delivery practice are intended to get your team comfortable with always being production ready.
Adopting Continuous Delivery will change your entire testing and release process, so it’s important to keep an eye on certain success measures to understand how your team is tracking toward your ultimate goal. The biggest success measures include:
- Decreases in the length of time feature branches and pull requests are open
- Decreases in the amount of time it takes your QA team to test a release
- Increases in how often you ship changes per week or per month
- Decreases in the amount of bugs in your staging environment (if this increases, you need to put more thought into the planning process to restructure changes to better avoid introducing issues in a live environment)
As these success measures continue to trend in the right direction, it’s a strong signal your team is ready to move to the next phase of adoption for Continuous Delivery.
Ready to get started? Contact us today to learn more about how Spaceship can help your team successfully introduce Continuous Delivery.