Devops - How I Learned to Stop Worrying and Love Deploys

While I was working on a presentation about DevOps for Sapient I did a lot searching for the best information and resources on the subject. I quickly realized that I wasn’t going to be able to condense all of that information in a 45 minute talk if I was supposed to speak at a speed anyone could understand. Hopefully this longer format will point people in the right direction for more information and provide background to the presentation you can view here. I’ll be breaking this into three sections and posting one per week along with a new block of sources and articles I found useful, so check back in for more information. With that, on to the show!

DevOps can make your life easier whether your in development, operations, QA, or project management. So sit back, relax, and see how I learned to stop worrying and love deploys with DevOps.

What is DevOps?

For the less text inclined, this Rackspace video provides a great summary of what DevOps is and what it’s goals are. For everyone else, the simple answer is that is a group of practices that aim to decrease the time between a change being made in a software project and getting data back on how that change is working in production. It accomplishes this by involving all members of the product team throughout the product lifecycle and leveraging automation to remove the need for manual intervention [3]. This drive for more, smaller releases means that an organization can make better, faster decisions and react to changes in the market more effectively [10].

The term “DevOps” was first coined in 2009 as an outgrowth of the Agile method of software development as it applied to computer infrastructure [2]. Being born out of Agile, it focuses more on people and how they interact rather than a specific set of tools or practices to achieve its goals. With a non-DevOps approach software was usually built by the development team and then handed over to the system administrators to deploy and maintain. The two groups had an imaginary wall between them which they tossed new code and bug tickets over to the other. DevOps attempts to break down this wall by involving both the developers and the operations staff in the entire lifecycle of the product [4].

This means that once a feature is finished, it is not the exclusive responsibility of operations to deploy and keep that feature stable, the development team has both the responsibility and the permission to fix issues. At the same time, operations uses the same kinds of tools as the developers to create and maintain their infrastructure’s configuration [4]. Thus, we break down the silo wall between the developer and operations teams, with some staff being more skilled in one field or the other but meant to work across disciplines with a focus on what will provide the most value to the client.

Additionally, there is no prescribed set of tools for implementing a DevOps workflow beyond some broad categories which allows individual teams to pick what tools are best for them. Familiarity with different programming languages and pre-built integrations can be major factors in selecting a solution as can a preference for an open source solution versus an enterprise support contract. The key is that you can form a robust DevOps practice around any of these tools if the team is willing to learn how to use them. It’s the culture of the organization, not the tools, which decides the success of a DevOps practice [8].

Lastly, DevOps is not an “all or nothing” proposition but has a model for nurturing a practice over time [2]. Since DevOps spans the entire product lifecycle there are multiple places where improvements can be made over time. While there are some dependencies between the optimizations, many can be made individually to focus on areas where a specific project has issues. If a product needs to be very reliable but is simple to deploy, more time might be spent on getting tests highly automated while still relying on a repeatable but less automated deploy strategy. This link provides a good overview of the maturity model for the different areas of DevOps practice.

What next?

Over the next few weeks I’ll be finishing out this series of posts with in depth discussions of the best practices and some of the tools you can use to implement a DevOps practice. When they’re ready you’ll be able to find links here or find them in the chronological list of posts. In the mean time, I’ve listed out a few good sources from my research that you can explore as well. Hopefully, you’ll find them as useful as I have in understanding DevOps and how you can use it in your organization.

What is DevOps?

What next?

References