The prevailing IT requirement tends toward doing more work faster, but with fewer resources to do such work, many companies must reconsider their traditional approaches to developing, deploying and maintaining software. One such approach, called DevOps, first gained traction as a viable software development and deployment strategy in Europe in the late 2000s. DevOps is a marriage of convenience between software development (Dev) and IT operations (Ops) that seeks to shorten the lifecycle for development/testing/deployment/maintenance by moving developers closer to a production software environment, and simultaneously giving Ops folks more input and visibility into the development process. The result –namely the DevOps approach — is also known as continuous delivery or continuous deployment, and relies on close collaboration and communication between Dev and Ops personnel.
Rather than traditional development lifecycles with distinct phases that must be completed synchronously, DevOps supports a process where different software builds are continuously being moved through the development lifecycle in parallel, though builds may be in different phases of development at any given moment. The result is a number of frequent, smaller releases, versus months-long development cycles that result in large-scale software upgrades or deployments just once or twice a year. That’s a long time to wait to deliver critical features or bug fixes, especially if your competitors adopt shorter cycles. When implemented correctly, DevOps has the potential to transform software development and deployment by saving time and money while increasing application security. For the purposes of this discussion, we include QA as part of Dev, because that’s where QA functions traditionally reside.
Go Down to the Crossroads…and Automate
Thus, DevOps resides at the crossroads of software development, IT operations and software quality assurance (QA). Just as a three-legged stool requires all three legs to provide a stable foundation, the DevOps approach requires participation from Dev, Ops and QA to succeed. Automation is also another typical requirement for the DevOps approach, simply because manually performing the myriad steps required to get software ready for release is not feasible when you deploy new releases weekly, daily, or even multiple times a day. Testing in a DevOps environment requires a serious investment in automation, from unit testing to integration testing to regression testing to QA testing to load testing to user acceptance testing. There is simply no way to adequately test an application without the capabilities and quick turnaround times that testing automation software delivers. Note that most testing automation software integrates easily with log file monitoring tools, and that the data garnered from those log files provides feedback critical to the DevOps process.
Bridging the Gap Between Dev and Ops
The whole point of DevOps is to shorten the time it takes for Dev and Ops teams to communicate. This collaboration cross-trains Dev and Ops personnel on the challenges and opportunities inherent to each team’s perspective. Developers gain important insights into how their software works—or doesn’t work—in the real world. Tight collaboration between Dev and Ops also gives the Ops team a channel to provide feedback directly to developers when they see a production issue with the application. Similarly, by asking developers to work side-by-side with Ops, those developers can learn far more about their software creations that they could ever learn while sitting in a cubicle somewhere, totally removed from a production environment. Such collaboration between teams, who are both equally responsible for the success of a software deployment, reduces finger-pointing by literally putting Dev and Ops on the same boat. Cross-trained personnel, well-defined communication processes and a team spirit are some of the substantial and competitive advantages that come from a DevOps approach.
Increasing Security While Driving Down Costs
The shortened DevOps development cycle offers one further critical advantage, almost by accident: increased security for your applications. Shorter development feedback cycles means that any security vulnerabilities discovered in testing or from user feedback can be addressed almost immediately. Microsoft, for example, typically issues bug fixes once a month on the aptly nicknamed Patch Tuesday. Have you ever thought about the exposure to users’ computers that might be vulnerable during the gaps between Patch Tuesdays? What about users who fail to download patches when they are released? DevOps avoids this conundrum by reducing the time it takes to fix critical security vulnerabilities in an application. Vulnerabilities discovered in production can be quickly routed to the proper Dev personnel so that the issue can be verified and addressed in timely fashion. This quick reaction capability is a key advantage for software developed using DevOps principles.
DevOps Focuses on Stakeholder Deliverables
Last but not least, a DevOps approach increases the focus of software teams on what really matters: delivering robust software on a compressed schedule that meets or exceeds the expectations of end-users, business teams and company management. With this in mind, remember that DevOps is not an end unto itself. Rather, DevOps is a useful tool that can provide visibility, agility, cost reductions, increased security and significant competitive advantages to a company developing software.
Earl Follis is a long-time IT professional who has worked as a technical trainer, technical evangelist, network administrator, and in other IT positions for a variety of companies that include IBM-Tivoli, Nimsoft (acquired by CA), Northrop Grumman, Thomas-Conrad (acquired by Compaq) and Dell. He’s also the co-author of numerous books, including …For Dummies titles on Windows Server and NetWare, and has written for many print and Web publications. His primary areas of technical interest include networking, operating systems, cloud computing and unified monitoring and management solutions.
Ed Tittel is a 30-plus year IT veteran who’s worked as a software developer, networking consultant, technical trainer, writer, and expert witness. Perhaps best known for creating the Exam Cram series in the late 1990s, Ed has contributed to over 100 books on a variety of computing topics, including numerous titles on information security and HTML. Ed also blogs regularly for Tech Target (Windows Enterprise Desktop), Tom’s IT Pro, GoCertify.com, and PearsonITCertification.com.