Back in 2015, Amazon set a new precedent for speed in software delivery, performing 50 million code releases in a year (which translates to more than one per second). Since then, speed has only increased. In fact, according to the 2017 State of DevOps Report, deployment frequency has increased 700 percent since 2015.
We owe this increase in speed in large part to the rise of DevOps, which McKinsey finds has helped teams reduce the time to move from code to production by as much as 74 days.
And given that DevOps hit 74 percent adoption in 2017, it’s clear that organizations of all kinds are clamoring for the ability to deliver releases more efficiently and more often that comes with taking a DevOps approach.
But how exactly does DevOps deliver on the promise to help you build, test and deploy applications more efficiently? It all comes down to continuous delivery, deployment, integration and testing.
Deciphering the DevOps Terminology
For all the promise that DevOps holds, it’s surrounded by just as much confusion. Between a new way to think about releases and a host of new terminology along the way, taking on a DevOps approach certainly requires a shift.
In making the shift to DevOps, one of the most important (and first) things you need to nail down is the terminology — especially when it comes to practices like continuous delivery, deployment, integration and testing — so that you have a clear understanding of what those practices are and how they can help you bring DevOps to life. Here’s what you need to know:
Continuous delivery is the idea that software should be ready for production at any time. While DevOps calls for a broader, cultural change in order to deliver releases on a regular cadence and do so more efficiently, continuous delivery is the tactic that helps that change come to fruition.
Some of the key components to getting continuous delivery right include rapid and regular code releases and regular testing. Having an automated release process and automated testing also help keep up with the rapid pace for which continuous delivery calls. Finally, as Martin Fowler points out, teams operating in a continuous delivery environment typically prioritize keeping software deployable over working on new features.
Whereas continuous delivery calls for software to be ready for production at any time, that doesn’t mean it goes to production automatically. That’s where continuous deployment picks up the baton.
With continuous deployment, every change that passes the necessary tests gets released into production, making it a natural follow-on to continuous delivery. To get to that point, both continuous delivery and continuous deployment require continuous integration and continuous testing.
Continuous integration (along with continuous testing) allows for continuous delivery (and therefore continuous deployment) by regularly integrating every new feature that gets developed back into the master code branch.
Essentially, continuous integration creates a regular feedback look so that the master code branch picks up any changes and merges those changes with the existing code. It creates an iterative process in which changes get added in piecemeal as they’re ready, rather than all in one big bang. This process not only allows for changes to get added in faster and more often from various contributors, but it also makes it easier to identify the source of any problems should an issue arise. As a result, merging changes with the master branch as often as possible and confirming those changes work by regularly running automated tests are critical to a smooth continuous integration environment.
Finally comes continuous testing, the process of executing automated tests as part of the software delivery pipeline in order to obtain feedback on the business risks associated with a software release candidate as rapidly as possible. It evolves and extends test automation to address the increased complexity and pace of modern application development and delivery.
In order to power this regular activity and quickly identify any issues, continuous testing relies heavily on automation and reporting. For instance, you might run an automated unit test every time a developer builds new code.
In general, continuous testing holds an extremely important role in DevOps environments, as it helps alleviate any bottlenecks that might get created by a traditional QA process in which testing happens all at once at the end of the development cycle. That’s because injecting testing throughout the development cycle makes it possible to identify and address issues earlier and more often. Additionally, if you don’t conduct any testing until the end of a development cycle, you no longer have software that’s ready for production at any time, making continuous testing an essential building block for continuous delivery.
Making Sense of DevOps Terminology
As more and more software development teams embrace DevOps, we’re entering a new playing field. From how often new releases get deployed to how developers and testers work together, there’s no doubt that DevOps has created a different type of environment. And while the promise of building, testing and deploying applications more efficiently can be quite alluring, in order to realize this goal, you first need to have a firm understanding of the tactics that power DevOps. Once you do, you’ll be well on your way to getting started.
Learn how the Tricentis qTest platform can help you transition to continuous testing with solutions like Tricentis qTest Scenario, the only enterprise-ready BDD solution for teams using Jira.