Here's everything you need to know about transitioning to Continuous Deployment: How to achieve it, the tools and processes we recommend, and the benefits.
Transitioning to Continuous Deployment
If you’re reading this, you’re probably thinking of making the transition to Continuous Deployment (CD). Or perhaps you’ve made the transition, but you still don’t feel as if you’re using your CD pipeline to its fullest potential.
Transitioning from monthly (or semi-monthly… or yearly 😵💫) releases to Continuous Deployment is a rewarding shift that will pay dividends for your entire organization. But, as with any new software development process you adopt, there are concrete steps that you’ll have to take to achieve a proper and fully functioning CD pipeline.
We’re going to walk you through those steps so that your team can adopt CD, regardless of how often you deploy code right now. Then, we’re going to explain how we made the switch to CD here at DevCycle, and the benefits that we’ve seen firsthand from doing so.
What is Continuous Deployment?
Before we get into how to achieve Continuous Deployment, we need to understand what Continuous Deployment is, and where it fits into the entire Continuous Integration/Continuous Delivery/Continuous Deployment workflow.
All CI/CD pipelines have to start with Continuous Integration (CI). CI is the process of building, checking and running automated tests that your code has to pass through to be merged to the main branch.
From there, we move onto Continuous Delivery, which is the process of ensuring that your code in main is always in a deployable state so that you can deploy it whenever you want to. Code is automatically deployed to a testing environment in this stage, but is not deployed to end users until you manually hit the “deploy button”.
The final step is Continuous Deployment. Continuous Deployment is the process of automatically deploying code to your end users if it has passed all tests and stages to production. When we talk about transitioning to CD in this article, we’re talking about Continuous Deployment. This is the ultimate end goal for most organizations looking to release code multiple times per day.
At DevCycle, we like to think of CI/CD as the process of eliminating the ceremony of releasing code. Gone are the days of massive, end of month releases with large change footprints. With CD, small releases and deployments happen so often (ideally multiple times per day) that they become a part of the fabric of your company.
How to Achieve Continuous Deployment
Make it a gradual transition.
When talking to a few of our engineering leaders here at DevCycle, they all agreed that your transition to CI/CD should be a gradual one. (So, please don’t expect to continuously deploy 3 new features on day 2 of adopting CI/CD – that will end very, very poorly.)
We suggest you start with smaller changes, and smaller chunks of work. Instead of trying to go from releasing code three times per year to multiple times per day, set a goal for yourself to release code every 2 weeks, and then move to weekly, then daily, and–eventually–you’ll be releasing code multiple times per day.
Aim for Continuous Delivery first, then move towards Continuous Deployment.
Our other suggestion is to move closer to Continuous Delivery before Continuous Deployment. Of course, Continuous Deployment is the end goal, but Continuous Delivery is a bit easier to establish (and it has to be well established in order for Continuous Deployment to happen, anyways.)
Recall above that Continuous Delivery is the process of ensuring that your code in main is always in a deployable state – i.e. you can deploy whenever you want to deploy, but it will not be automatically deployed. From here, you will still have to manually hit "deploy" to release the code to end users. We recommend aiming for Continuous Delivery before Continuous Deployment for a few reasons.
First, moving right to Continuous Deployment is a large jump for teams that are used to manual releases and being able to manually review their code before it gets released to their users. Continuous Delivery is an easier adjustment as it gives you the chance to double check everything before it’s released to your end users.
Additionally, becoming comfortable with Continuous Delivery before Continuous Deployment gives you the chance to really validate and trust your tests. When you set up Continuous Deployment, your end users see any and all code that has passed your tests, so you need to be sure your tests are solid (i.e that they’re not letting buggy code pass through and/or that the bugs that do pass through are not critical).
With Continuous Delivery, you have a chance to see how your code is performing and manually validate it after it’s been tested. If you notice a bunch of errors and bugs in your code in the production environment, that probably means something is off with your tests. Thus, starting with Continuous Delivery gives you the chance to validate and ensure that your tests are actually doing their job and not letting buggy code pass through before you move onto Continuous Deployment.
Start with simple, low-risk code changes.
Our last piece of advice is to start with simple changes and low-risk updates when adjusting to CI/CD. Admittedly, adjusting to CI/CD takes time, confidence, and buy-in from your entire organization. Automating your tests and deployments may feel scary at first – especially for those responsible for building the tests. Starting with small, low-risk code changes allows your team to adjust to the process and gain confidence in it before moving to larger feature releases.
Once you become comfortable with Continuous Integration and Continuous Delivery, Continuous Deployment awaits. Here are some practical steps you can take to set up a proper CI/CD pipeline (in even the oldest and largest legacy codebases):
Step 1: Set up your pipeline.
The obvious first step is setting up a CI pipeline. This requires building out your tests and setting up a pipeline that ensures your code can be merged once it has passed said tests. (See content on CI above.)
Step 2: Tests.
The second step is to have a set of tests (that you trust!) in place.
Once your code passes those automated tests with CD, it’s released. Thus, you need to ensure your tests are trustworthy enough that you don’t need to manually review your code after, because you won’t be manually hitting “deploy” once your code passes them.
Let it be known here that, to start out, your tests don’t have to be super complex because you’re not going to be using CD for complex changes at first. They simply have to be end-to-end tests that, at the very least, confirm your site and/or platform work how your team intends. For example, for DevCycle, these basic end-to-end tests would ensure that our users can access DevCycle, log in, and create a new feature.
Eventually–when you have a fully fledged out CI/CD pipeline and you’re using it for almost all deployments, regardless of size & impact–you’ll want more complex and comprehensive testing in place. But for today’s purpose of simply getting started with CI/CD, basic tests are all you need.
Step 3: Set up centralized logging or error management.
This ensures that when an error does happen (i.e. when buggy code makes it past all of your automated tests and gets released to your end users), you’re able to track down where it came from, and quickly address it. We’re not at all suggesting this one to create a culture of blame. It’s simply a necessary step when you’re automating so much of your test and deployment process.
Additionally, the good thing about CI/CD is that you’re deploying smaller, incremental code changes multiple times per day as opposed to massive code changes with a large change footprint once a month. Thus, using an error management platform with CI/CD is a much simpler process since the releases are so small and it’s easier to find exactly where an issue is.
Step 4: Use feature flags.
We’ve already mentioned that Continuous Deployment can be a large adjustment for teams who are used to manually reviewing everything.
Sure, automating your test and deployment process speeds everything up because you’re eliminating the need for human intervention, which means your developers can spend more time actually writing code. BUT automating your deployments and giving up manual intervention can still feel scary. Using feature flags alongside CI/CD is an added cushion – a safety net, if you will – that boosts your team’s confidence in automated deployments.
Feature flags allow developers to turn features on or off without requiring them to redeploy their code. They act as a safety net for any dev team using CI/CD, because they make it easy to turn a feature off that isn’t performing correctly. Thus, in the event that buggy code makes it past your automated tests and into your users’ hands, you can simply toggle the feature off and your users will revert back to the original functionality – all without needing to redeploy code or update your application.
Our Firsthand Experience with CI/CD
Our transition to CI/CD here at DevCycle was a bit unconventional: We adopted a CI/CD pipeline in an entirely new codebase when we launched DevCycle. Admittedly, starting fresh with CI/CD is probably easier than implementing CI/CD into an existing codebase since we were able to cherry pick all new tools and processes and write entirely new tests.
But, as we proved in this article, achieving Continuous Deployment in even the largest and oldest of legacy codebases is possible if you follow the steps outlined above. Our work to move our previous legacy codebase, Taplytics, towards CI/CD is proof. We implemented a CI/CD pipeline into Taplytics’ codebase after it had been around for a few years. With Taplytics, we were able to move from releasing code every few months to a Continuous Delivery pipeline that allowed us to release every week. This taught us a lot about what to test, how to speed up builds and how to automate deployments before building a fully functional Continuous Deployment pipeline within DevCycle.
The Benefits of Continuous Deployment
Increases deployment frequency, decreases cycle time.
Continuous Deployment has enabled us to get code to production in as little as 15 minutes. This is a massive increase in deployment frequency compared to the 3.5 month release cycle we had with Taplytics. We’re able to release and iterate faster, respond to user feedback in real time, and deploy code multiple times per day.
### Boosts developer productivity.
When your developers don’t have to manually test and deploy their code, they have a lot more time on their hands to actually write code. CD significantly de-burdens our developers from the QA process and deployments so that they can spend their time and energy actually building DevCycle.
Makes developers better at their job.
Automating our tests and deployments with CI/CD has required our developers to really think about the work they’re doing. They have to ask themselves “is this code well tested?” and “is it well thought out?” since they’re relying on the checks and balances system that they build themselves for automated testing.
Easier to debug.
Any release you put out with CD is small enough where it’s very easy to find bugs. It can take weeks to find a bug in big releases that have large change footprints. When you release code with CD and something goes wrong, you know which release the bug belongs to and mitigating the bug takes less time.
Less stress, more confidence.
And since we deploy smaller and incremental changes with CD, the stakes are much lower and our developers are rid of the “post-code release anxiety” they used to feel with monthly releases. Without big bang releases, we can ship with confidence knowing that (likely) none of our changes will impact or break our entire platform. And if there is a bug in code, we know that we can easily rollback the changes or toggle the functionality off with feature flags.
The Bottom Line
Transitioning to Continuous Deployment is a big shift that requires buy-in from your entire organization to make work. While it may take some time to adjust to and some trial and error to set up the pipeline, the adjustment period is worth it. Once your CD pipeline is up and running properly, you’ll be deploying more frequently and automating more than you ever thought possible. Visit our CI/CD resource page for more info, or set up your DevCycle account today at app.devcycle.com
Top comments (0)