By Daniel Greene
As is evident from the increase in conferences, books and software tools, there is a growing emphasis on improving DevOps within all sizes of software development organizations. The question that follows is typically, “What is DevOps?” This is an absolutely understandable question. Not only is it a relatively recent movement within the software community, but the commercial marketing machine has taken over ownership of the term, bending it to their needs.
This is nothing new. SOA, ESB, and cloud computing have received similar treatments. Four to five years ago, a massive amount of integration products were quickly renamed ESBs, and SOA was infamously declared dead due to the level of marketing hype. Don’t even get me started on the Microsoft “To the Cloud!” ad campaign for its picture-editing software.
Yeah, But Really, What Is DevOps?
Historically, product managers, business analysts and software engineers would work together to organize a release plan, with user stories sequenced into iterations that could be re-prioritized at each iteration boundary. While every iteration is supposed to end with a “production ready” version of the system, it has not been common to actually release to production regularly.
More often, the output of an iteration makes it only as far as a “test” or “staging” environment, because actually pushing to production requires many more steps: bundling the code, packaging the product, provisioning the environment, and coordinating with the operations staff.
People began to realize that a “throw it over the wall” mentality from development to operations was just as much of a challenge as we used to have with throwing requirements over the wall and waiting for code to come back. People began to blur the lines between the development tasks, such as coding and operational deployment tasks such as server provisioning, hence the name “DevOps.”
I still don’t see a clear definition in there…
As mentioned above, the term DevOps has been used for many areas: automated infrastructure provisioning tools (e.g. Chef and Puppet) and automation tools (e.g. continuous integration like Jenkins), as well as for establishing developer work environments to mirror production (e.g. Vagrant).
I use the term “DevOps” to define a set of practices, tools and policies that lead to improved quality and Automated Delivery (AD). In many ways, rapid and frequent deployment to production reduces risk, as any release contains fewer changes. And fixes for any issues that are found are easier to fix or, alternatively, the smaller changes are typically easier to roll back.
So, DevOps is the same as Automated or Continuous Deployment then?
Almost. DevOps, in a way, is all the things that go into making AD/CD possible. In many ways, DevOps is about ensuring quality at all stages.
You can visualize DevOps as a conveyor belt, where many checks and balances are in place, at all stages, to ensure any bundle coming down the belt is removed if it’s not good enough, and delivered to the end of the belt (e.g. production) safely and reliably if it is.
Why should I care? What will DevOps do for me?
DevOps practices and procedures lead to smoothing out the typically ‘bumpiest’ aspects of software development and deployment. By pulling infrastructure setup and awareness earlier in the development cycle, surprises from environmental differences are significantly reduced.
By establishing consistent, reliable and repeatable automated deployments, human error and the need for ‘rockstar firefighters’ are reduced. The Phoenix Project (Kim, Behr, Spafford) is a great read on the subject and chronicles an organization’s change to embracing these practices in an incremental and prioritized manner. One of the key takeaways from the book is that making the first step is difficult, but allows for the next step to be easier.
Defining DevOps and integrating it into your processes at all levels
Most of the talk, tools and processes around DevOps can be intimidating. The Herculean task of transitioning to fully automated, multiple production releases per day can be daunting. The truth is that level of automation is simply not needed for all products or companies.
How deeply clients incorporate DevOps into their practices varies wildly; some still want a formal ‘hand off’ process, which DevOps purists will rage against. For these clients, a fully automated endto-end system may convey far too much risk. Do what alleviates the greatest pain for your organization in the development to release cycle. Like agile programming taking incremental steps toward the end goal is the most effective and reliable way of reaching the goal.
Software product businesses commonly aim to be ahead of their competition by launching new products and features quickly to market. Agile product development teams are expected to adapt to business changes and challenges while maintaining high quality standards.
More clients are recognizing the need for, and asking for help with, developing effective strategies to continuously deploy new/updated software; keeping systems up around the clock; and quickly and seamlessly resolving operational issues quickly.
If you leverage DevOps practices to assist in smoothing the worst point in your cycle, you may discover that your pain level has been lowered to the point where your releases are in sync with the velocity of customer feedback, and you can hold and/or hone your existing processes.
Like traditional software development, introducing capabilities that are not needed or of high value is a waste of development resources. You know by now that many business demands can be managed with DevOps practices and processes. That’s why I’m excited by DevOps initiatives.