Solving the Last Mile Problem for Continuous Delivery

This post is the fifth and final article in our Tactical Guide to a Shorter Cycle Time five-part series. Read the previous post here . If developers’ changesets aren’t always deploy-ready upon merging, your team is not practicing Continuous Delivery. The final step to fully optimizing your time to market (or your Cycle Time) is to indoctrinate seamless deployment, holding every engineer responsible for keeping the main production branch in a releasable state. Impediments to true Continuous Delivery fall into three categories: : Your process involves many manual blockers, including QA and manual deployment. Process : Your managers or engineers lack confidence. They’re not sure whether defects will be caught before merging or whether their team can respond to issues uncovered after deployment. Behavioral : Your current tooling is either lacking, too slow, or breaks frequently. Technical This post will walk you through mitigating each obstacle so that you can achieve a deploy-ready culture on your engineering team. Work through Process Impediments Transitioning to a CD process requires every person on your development team to spend their time as strategically as possible. This ruthless approach to time management requires automating everything you can in the deployment process— particularly, any manual phases that completely block deployment. On many teams, the hardest transition is moving away from a process in which humans gate shipping, such as manual QA and security checks. These stamps of approval exist to give your team confidence that they’re not shipping anything that isn’t up to snuff. To eliminate these blockers, you’ll need to address quality concerns throughout your software dev process—not just at the end. Remove QA as a Blocker to Deployment The purpose of testing, whether manual or automatic, is to ensure software quality is up to standard. Many of the practices within CD, such as working in small batches and conducting Code Review, inherently serve as quality control measures. Any major defects that your team doesn’t catch during development should be caught with automated testing. To reduce the risk associated with removing QA as a blocker: Where and what you test will depend on a multitude of factors, but consider as possible to ensure developers can make changes before putting in too much work. Automate testing throughout the software development process (not just at the end). testing as early Overtesting may lead to long build times and will simply replace a manual bottleneck with an automated one. We recommend trying to ensure that test coverage is sufficient enough. If an issue isn’t caught and does break in the middle of the night, it doesn’t require waking up an engineer. Do not overtest. If there are deployment risks that you have not yet mitigated, use to roll out changes either internally or to a small sample of your customer base. For further research, check out Launch Darkly’s full e-book on . Use feature flags and dark launches. feature flags Effective Feature Management Once you have these components in place, you’ll want to make sure you have an effective monitoring system, where your tools surface issues as quickly as possible. Measuring Mean Time to Discovery (MTTD) alongside will help you consistently track and improve the efficiency of both, your monitoring and your pre-deploy testing suite. Mean Time to Recovery (MTTR) Shift Security & Compliance Checks left Security is one of the most important checks before deployment, which is why you shouldn’t leave it open to human error. Enable your security experts to think strategically about what kind of testing they should run, while leaving much of the tactical security work to the machines. To integrate security throughout your software delivery process, consider: Whenever a feature that handles particularly sensitive data is coming down the Continuous Delivery pipeline, include your security team in the planning and design process. This way, security considerations are baked into the process and front-of-mind for the team as they build out the feature. Involving security experts into the software planning and design process. , SAST remains one of the best ways to keep your application secure. Automated SAST tools detect , such as broken authentication, sensitive data expose, and misconfiguration. Automated source code scanning (SAST): With 80% of attacks aimed at the application layer all of the most threatening application risks Frequently called black-box testing, these tests try to penetrate the application from the outside, the way an attacker would. Any DAST tool would uncover two of the most common risks— and . Automated dynamic testing (DAST): SQL injection (SQLi) cross-site scripting (XSS) The is a dictionary maintained by the Cybersecurity and Infrastructure Security Agency that you can use as a reference to make sure your automated testing has covered enough ground. Automated testing for dependence on a commonly-known vulnerability (CVE): CVE With the above covered, your security team can apply their expertise to create tools for the rest of the team in the form of modules or primitives. This way, they’ll enable developers without security training to write systems that are secure by default. Building secure and reusable infrastructure for the team. Naturally, there will always be manual work for your security team, such as penetration testing. If you’re folding security into your development process, however, it won’t become a bottleneck at the very end of the process, stopping features from getting out to customers. Work through Behavioral Impediments found that organizational culture is the most significant barrier to CD implementation. A survey conducted by DevOps Group The behavioral change required to foster a culture of Continuous Delivery is the most difficult, yet the least discussed, aspect of adapting true CD practices. Your team needs to have confidence that their testing infrastructure and ability to respond to changes are strong enough to support Continuous Deployment. To instill this certainty, you’ll need to create alignment around CD benefits and encourage best practices throughout the software delivery process. Create Organizational Alignment on Continuous Delivery If properly communicated, the Continuous Delivery pipeline should not be a hard sell to engineers. CD unblocks developers to do what they like most—building useful software and getting it out into the world. Three intended outcomes will help you get both managers and engineers invested in Continuous Delivery: If the testing infrastructure is solid (more on this below), and the developers agree that it’s solid, they will feel more comfortable shipping their changes upon merging. Less risk. for the individual developer. When developers have the power to merge to production, they feel more ownership over their work. Due to sheer expectations of speed, the Continuous Delivery pipeline minimizes top-down planning and gives developers the ability to make more choices related to implementation. Higher impact Because ownership over a feature isn’t siloed in one individual, the software development process becomes much more collaborative. Distributed ownership over features eliminates some of the anxiety (and potential blame) when developers decide to ship their changes to production. Less blame. Equip Your Team for Change with Best Practices Thus far, our has included dozens of best practices that you can share with your team. In addition to these phase-specific optimizations, you’ll also want to coach these general principles: Tactical Guide to a Shorter Cycle Time five-part series When developers are scoping a Pull Request, they should be thinking: what is the smallest valuable step I can make towards this feature? When they’ve scoped and built that Pull Request, it should be deployed to production. They should avoid long-running feature branches. Work in small, discrete changes. Have developers minimize work in progress as much as possible. If you’re using a Kanban board, this means prioritizing items that are closest to done. Always prioritize work closest to completion. Don’t be surprised if this transition process takes over six months. The confidence required from your team will take a long time to build as they become accustomed to this new work style. If you’d like to move quickly, adopt CD with a team of early adopters who are already interested and motivated to make a positive change. You can learn from adoption friction in a small environment to better ease the larger organization transition. Work through Technical Impediments Your team can’t overcome either behavioral nor process impediments unless they have confidence in their suite of CI/CD tools. Builds that perform automated testing and deployment should be fast and reliable, while your monitoring set up gives you clear and instant visibility into how things are running. Sharpen Your Tools You’re not able to ship features to customers multiple times a day, if either: Your build is flakey, or Your build is slow. And even if your tests pass, your team won’t have the confidence to set up automatic deployment, if: Your monitoring isn’t thorough, or Your monitoring isn’t well-tuned. Again, a safe way to test the waters is to use dark launches or feature flags. Your team will be able to test how quickly issues are caught and how quickly they can recover—all without compromising the customer experience. As you work to improve your testing builds and monitoring, we recommend slowly transitioning your manual deploy schedule to a more frequent cadence. Start with weekly deploys, then daily, then multiple deploys a day. Finally, automate the deployment process once pressing the deploy button feels like a waste of time. The Holy Grail of Software Delivery Every article in our series has guided you through optimizing each phase in the software delivery process. If you’ve been successful with this, then your developers are making small incremental changes, pushing frequently, and moving work through the Continuous Delivery pipeline with little to no friction. But unless you’re actually shipping those changes to production, you’re not practicing Continuous Delivery. The point of CD (and Agile before that) was to shorten the feedback loop between customers and engineers. Working incrementally, but still shipping massive releases, does not accomplish this objective. Deliver continuously to mitigate risk, respond quickly, and get the best version of your software into the hands of customers as quickly as possible. Check out the other articles in our Tactical Guide to a Shorter Cycle Time five-part series: - Part I: The Virtuous Circle of Software Delivery - Part II: The Single Greatest Lever in Shortening Cycle Time - Part III: How to Stop Code Review from Bottlenecking Shipping - Part IV: Keep Code Review from Being a Waste of Everyone’s Time - Part V: The Last Mile to True Continuous Delivery