The Evolution of CI/CD and Agile

It’s nearly the end of 2018 and we still discuss CI/CD and agile as separate concepts. The truth is, the line between them is blurring. Doing either or both well is very difficult. In fact, many organizations struggle to effectively execute an agile workflow, or reach CD because they are so difficult to do well. This article focuses on why it is so important to keep striving toward this gold standard duo because CI/CD and agile result in quality and predictability.

Using Agile to Enforce High-Quality Practices

Why is doing agile well so important? From one perspective, agile is the human element of CI/CD. Sizing work, creating user stories directly mapping to value, breaking stories down into consumable tasks, estimating what can be done in a fixed period, conducting demos, and meaningful retros: all these efforts are similar to a code deployment pipeline. Should any part of it break down, velocity suffers, deployments are delayed, quality is impacted. 

Benchmarks like velocity are not new, formal agile has been branded since the early 2000s summit, but the practices are much older. Now that automation technology has vastly improved, humans are becoming a larger bottleneck. Since human bottlenecks are a matter of reality, success lies in setting agile teams to not only be successful, but to remove as many barriers as possible.

Where many organizations historically focused on metrics like bugs squashed, sprint points carried over, and others, there are now many articles focused on measuring agile team happiness or morale (henceforth motivation). It may seem ridiculous, but the shift to measuring team motivation is for a good reason. Motivated teams produce more. Eliminating negative influencers intrinsically should increase quality in all aspects of agile workflows. Things like: a scrummaster who actively dumps “surprise” tickets onto the team, focusing on sprint “failure” as the team failing, ignoring learnings in sprint retros—these sorts of activities reinforce a negative loop which drives down productivity and quality. Rather than spending time and effort on getting as many story points across the line, or counting how many bug tickets are generated from the last sprint, look for the bottlenecks (such as the labor of ticket management through workflows), look into how the team is doing from a morale perspective. The evolving agile team fixes the human elements first, then focuses on automating away annoyances through tools, and then delivers software efficiently.

Testing, Testing, Testing

It can’t be said enough. Testing is the reflection of quality. Considering the heavy time investment testing requires, it may seem like a counter-intuitive point, but testing is what speeds up agile team development. It will make the CD possible in the pipeline. Implementing automated test frameworks can be challenging for organizations who have relied on manually testing through QA runbooks, or worse, testing was ignored. If your organization is in this situation, and you keep getting asked how to speed up release delivery: invest in testing.

Why is testing stitched between agile and CI/CD? It drives quality. Some shops use test coverage as a winning metric, or a badge of honor and for good reason. If a company’s platform team can boast, we have 90% test coverage which is over 10k tests, that directly eliminates manual regression testing for 10k tests before each release. Imagine the delay if a QA team executed scripts or performed regression testing to cover 10k use-cases on each release! This is exactly why waterfall workflow and quarterly (or more) software releases are rampant in enterprises when you consider they are now taking old stacks and catching up in the agile and DevOps space. When automated testing passes all checks, that raises confidence when merging into CI and further along the pipeline, it also provides a fast feedback loop. If a new merge fails tests, the change isn’t integrated and the developer can make the update and submit a fixed PR (without waiting for QA to catch the mistake).

Tools are evolving to aid in the testing process. API testing such as Runscope, UI testing like Selenium, application release automation (ARA) such as XebiaLabs, and workflow suites like TravisCI help close the loop on the long haul of high-quality, full-test coverage.

Ultimately, creating rich testing is the real key to reaching CD—a task that is not for the faint of heart. Think of how much confidence you must have in your automation suite to allow changes to go from a pull request merge into a development branch and run all the way to production either with a button push (Delivery) or automatically (Deployment).

What CI/CD Does for Business  

In summary, it allows for high quality, frequent, software releases with minimal hassle. It sounds impressive and difficult because both are true. Imagine the power of fixing a bug or adding a feature and creating a PR. Then, sometime later, it’s in production and it’s on to the next thing. Customers get immediate (tested) features, ops teams don’t have to prepare for a rollout, and change management doesn’t have to labor over whether or not the changes will break something. It’s end-to-end efficiency. CI/CD is taking all those manual processes that lived in run books, ITIL meetings, and after-hour coordination and turns them into a button push.

A CI/CD pipeline is the mechanics of reliably delivering code, but what makes it work is the maturity of the testing. That’s it. The more thorough the testing, the easier code is promoted between environments with confidence and deployed to the next stage. There used to be a tremendous amount of work to create software-driven pipelines but now many popular code repository services such as Gitlab, Github, and Atlassian Bitbucket have made a tremendous effort in the past few years to enhance their services and integrations of a CI/CD pipeline to enable teams to speedily achieve CD. Newer players such as Codefresh also provide many tools to accelerate building container-based pipelines.

Adopting and evolving software stacks into CI/CD pipelines is liberating. Many organizations are hamstrung by change management boards or release control committees. These groups are put in place because of the high risk of production change. Production changes often impact revenue (especially if they go poorly). Scaling and speeding software delivery that relies on these boards means it is an expensive human problem that will never truly be fast or efficient. Truthfully, human-based change management doesn’t scale and it certainly isn’t competitive in today’s landscape of cloud-born companies. The money is much better spent full diving into testing and creating automated pipelines.

Building for CD is not as easy as just building great tests. It takes time to gain confidence and work through the growing pains. It takes time to build the trust within an organization to allow for changes to fire without a human checking everything. This may be less true with cloud-born startups, but they have an extreme advantage because they are starting with automation. It makes sense for a startup to stitch together open-source products, build full test coverage and push into pipelines from the start. Enterprises are struggling to catch up to not only create stateless, automated, scalable stacks from their previously administered, distributed environments but to build testing and pipelines in hopes of eventually releasing with confidence. Many enterprises are doubling down on these efforts because CD is a competitive advantage.

Bringing Agile and CI/CD Together

Closing the gap is no longer a technology problem. It never really was, the technology has simply improved. It is a human problem. Again, newer organizations are often born thinking agile and CI/CD, so how do you cope if you’re not a new organization? Often times, full adoption failure lies in one or both of two related problems: poor buy-in and unrealistic expectations. Conversely, agile and CI/CD are successfully implemented by starting with testing and starting small.

Poor buy-in and unrealistic expectations lead to abysmal adoption. Examples are: having teams commit to multiple sprints of work, expecting code complete on fixed dates, expecting pipelines to be a silver bullet to high-quality software. Too often large enterprises make the mistake of not only making agile “waterfall-like” but they insert all their manual processes into pipelines (such as change management). Making these mistakes is an indication that the business is not “all-in” on the evolution.

For higher adoption success, allow dev teams to pull in a reasonable amount of work each sprint and measure their happiness. Allow extra time to learn the new technology, to have proper time to write tests, to have the business maturity to allow room to fail (in code and sprints). It could mean making hard decisions to change an application or stack to support CI/CD workflows better. Every part of the application ecosystem that cannot successfully fall into reliable code tests and delivery through automation will anchor your competitive edge.

Summary

Agile and CI/CD are merging closer to becoming a single, high-quality, predictable method to release software. There are human and technology elements to solve for each to work in harmony, but the effort is worth it. Testing is the key to reaching CD, and when you can deploy with confidence at the push of a button—you will have far more time for innovation and waste less time with the inefficiencies of the old ways.