So you’ve heard about all the great things that DevOps has to offer, and are excited to jump in and start embracing DevOps practices at your organization. The only problem is that you’re now asking yourself, what exactly does DevOps entail?
Like all cultures, DevOps has many variations on the theme. However, most observers would agree that these six capabilities are common to virtually all DevOps environments:
3. Continuous integration
4. Continuous testing
5. Continuous delivery
6. Continuous monitoring
Below we offer a brief description of each element, adapted from our latest eBook, “Navigating DevOps.” If you’re new to DevOps or simply want to brush up on your understanding, the eBook is a perfect primer.
Instead of pointing fingers at each other, development and IT operations work together (no, really). While the disconnect between these two groups created the impetus for its creation, DevOps extends far beyond the IT organization, because the need for collaboration extends to everyone with a stake in the delivery of software. As Laurie Wurster et al. explained in this Gartner report:
Successful DevOps requires business, development, QA, and operations organizations to coordinate and play significant roles at different phases of the application lifecycle. It may be difficult, even impossible, to eliminate silos, but collaboration is essential.
DevOps relies heavily on automation—and that means you need tools. Tools you build. Tools you buy. Open source tools. Proprietary tools. And those tools are not just scattered around the lab willy-nilly: DevOps relies on toolchains to automate large parts of the end-to-end software development and deployment process.
The only caveat: Because DevOps tools are so amazingly awesome, there’s a tendency to see DevOps as just a collection of tools. While it’s true that DevOps relies on tools, DevOps is much more than that.
3. Continuous Integration
The continuous integration principle of agile development has a cultural implication for the development group. Forcing developers to integrate their work with other developers frequently—at least daily—exposes integration issues and conflicts much earlier than is the case with waterfall development. However, to achieve this benefit, developers have to communicate with each other much more frequently—something that runs counter to the image of solitary genius coders working for weeks or months on a module before they are “ready” to send it out into the world. That seed of open, frequent communication blooms in DevOps.
4. Continuous Testing
The testing piece of DevOps is easy to overlook—until you get burned. As one industry expert puts it, “The cost of quality is the cost of failure.” While continuous integration and delivery get the lion’s share of the coverage, continuous testing is quietly finding its place as an equally critical piece of DevOps.
Continuous testing is not just a QA function, in fact, it starts in the development environment. The days are over when developers could simply throw the code over the wall to QA and say, “Have at it.” In a DevOps environment, everyone is involved in testing. Developers make sure that, along with delivering error-free code, they provide test data sets. They also help test engineers configure the testing environment to be as close to the production environment as possible.
The payoff from continuous testing is well worth the effort. The test function in a DevOps environment helps developers to balance quality and speed. Using automated tools reduces the cost of testing and allows test engineers to leverage their time more effectively. Most importantly, continuous testing shortens test cycles by allowing integration testing earlier in the process.
5. Continuous Delivery
In the words of one commentator, “continuous delivery is nothing but taking this concept of continuous integration to the next step.” Instead of ending at the door of the development lab, continuous integration in DevOps extends to the entire release chain, including QA and operations. The result is that individual releases are far less complex and come out much more frequently.
The actual release frequency varies greatly depending on the company’s legacy and goals. For example, one Fortune 100 company improved its release cycle from once a year to once a quarter—a release rate that seems glacial compared to the hundreds of releases an hour achieved by Amazon.
Exactly what gets released varies as well. In some organizations, QA and operations triage potential releases: many go directly to users, some go back to development, and a few simply are not deployed at all. Other companies—Flickr is a notable example—push everything that comes from developers out to users and count on real-time monitoring and rapid remediation to minimize the impact of the rare failure.
6. Continuous Monitoring
Given the sheer number of releases, there’s no way to implement the kind of rigorous pre-release testing that characterizes waterfall development. Therefore, in a DevOps environment, failures must be found and fixed in real time. How do you do that? A big part is continuous monitoring.
According to one pundit, the goals of continuous monitoring are to quickly determine when a service is unavailable, understand the underlying causes, and most importantly, apply these learnings to anticipate problems before they occur. In fact, some monitoring experts advocate that the definition of a service must include monitoring—they see it as integral to service delivery.
Like testing, monitoring starts in development. The same tools that monitor the production environment can be employed in development to spot performance problems before they hit production. For a full list of DevOps tools (and more DevOps-related content), visit New Relic’s DevOps Hub.
Learn more about what DevOps is and why it matters to your business. Download the eBook, “Navigating DevOps,” now.