BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Practices for DevOps and Continuous Delivery

Practices for DevOps and Continuous Delivery

Bookmarks

DevOps is an attempt to break the barrier between development and operations teams, who are both required for the successful delivery of software says Danilo Sato. His book Devops in Practice: Reliable and automated software delivery provides a hands-on approach for implementing continuous delivery and DevOps practices.

InfoQ readers can download a sample of the book "DevOps in practice" to get an impression of this book.

InfoQ interviewed Danilo Sato about why processes tend to become bureaucratic and how you can prevent this, his view on DevOps, practices for DevOps and continuous delivery, automating the configuration of the infrastructure, continuous improvement, and how developers, testers and people in operations can learn DevOps practices and find ways to work together more closely.

InfoQ: What made you decide to write a book about DevOps in practice?

Sato: Even though I’ve been a developer for most of my career, my first paid job in technology was as a system administrator for my University’s Linux network. That background made me interested on the operational side of software: it wasn’t just about writing code, but how to make it run – and keep running - in production. I always gravitated towards helping my teams with troubleshooting build issues, setting up CI and deployment pipelines, provisioning infrastructure, automating deployment. This made DevOps a natural topic to cover on my first book.

InfoQ: The book uses a "hands-on" approach by providing detailed descriptions for installation and configuration. Can you elaborate why?

Sato: Meeting and talking to clients, I noticed that they could understand the benefits of Continuous Delivery and its principles, however it was hard to put them in practice. My coaching approach has always been to teach by solving problems. If you understand a problem, it is much easier to learn a new technology/technique if it solves that problem for you.

Writing the book was my attempt to share with the community a very practical and hands-on example of implementing Continuous Delivery and DevOps.

InfoQ: You mentioned in the book that over time deployment processes tend to become bureaucratic. Why does this happen, and are there ways to prevent this from happening?

Sato: Process is usually introduced as a way to prevent failures that happened in the past. A typical example is a story like: “we had a problem last time we deployed system X because we forgot to update the database configuration”, and the solution is to add a process step to have a board to review and approve any configuration change before it can go to production. The goal is to avoid repeated problems, but the implementation brings other problems. More process reduces the frequency of deployments, which increases the amount of changes that go in each release, which increases the risk of introducing problems. From a Systems Thinking perspective, this is a vicious cycle.

If instead of adding bureaucracy and ceremony, you invest in automating the process of releasing software, you can break that cycle, and this is where DevOps practices make the difference: you can release more frequently, which reduces the amount of change in each release, reducing the risk for each release. When a problem happens, it is much easier to find the root cause because the change surface was smaller.

InfoQ: Can you share your view of what you consider that DevOps is and isn't?

Sato: DevOps is an attempt to break the barrier between Development and Operations teams. They are both required for the successful delivery of software, but have been traditionally split into separate organizational silos with competing goals. While developers are responsible for delivering new features and responding to change, operations have to keep everything running smoothly and avoiding change is one way to reduce risk. DevOps is focused on automation and measurement as a way to reduce the risk and collect data to improve the delivery process, but it’s a lot more than using a new tool.

It’s about people from different backgrounds collaborating to enable fast and reliable software releases. And this is something that a lot of people miss: instead of bringing people together, they create a new “DevOps team”, which can make things worse because it’s yet another silo in the picture. ThoughtWorks has put the practice seperate DevOps team on hold in our Tech Radar to highlight how dangerous this can be. A successful DevOps adoption impacts the company’s culture and goes way beyond technology.

InfoQ: Can you give some examples of DevOps practices that you recommend to teams?

Sato: An easy one to implement is to keep everything in source control. This allows both application and infrastructure changes to be auditable and traceable, but also to have automated tests to validate their quality before they get applied to production.

Automating the build and deployment process for your application is also very important. Not only it makes the process run faster, it also reduces the risk of human errors when deploying software to production.

Another practice that I like to implement on my teams is to develop on production-like environments. Reducing the discrepancy between development and production allow developers to find problems faster. A few examples of discrepancies that I’ve seen create problems: developing on Windows machines and deploying to Linux servers in production; running against different database systems or application servers; having different versions of libraries and dependencies;

InfoQ: Same for continuous delivery, which practices do you suggest that teams should deploy?

Sato: I don’t usually make a distinction between DevOps and Continuous Delivery practices, since they are so inter-related in how I approach software delivery. However, a key practice that underpins CD is the deployment pipeline. It goes beyond having a CI server building and testing your application on every code change. A deployment pipeline is a model of the entire delivery process from commit to production.

InfoQ: What makes these practices so valuable?

Sato: A lot of these practices rely on automation, which allows breaking the vicious cycle that I talked about earlier. They enable more frequent deployments and shorter cycle time, which are great metrics for understanding the performance of your IT organization. And a high performing IT organization is a competitive advantage in the market today, as more business rely on technology to reach their customers.

InfoQ: Your book talks about "infrastructure as code",  automating the configuration of the infrastructure. Can you give some examples how this can be done?

Sato: Instead of having people manually connecting to a server to configure the operating system, install the base packages, deploy the application and its dependencies, you express those steps in code. Then you can use tools like Chef, Puppet, Ansible, or Salt to automate the provisioning process. Once you treat infrastructure as code, you can use version control to keep track of all changes made to the infrastructure, and you can put quality checks in your deployment pipeline to automate the release process of your software from development all the way to production.

InfoQ: Can you give some advice on how to do continuous improvement with DevOps?

Sato: Continuous improvement is an exercise in applying the scientific method of creating a hypothesis, performing experiments to collect data that validate or reject the hypothesis and iterating on that. With DevOps, you can increase the deployment frequency, which allows you to run this loop much faster. There are more opportunities to re-evaluate the delivery process and improve it through: better automation, better testing, better monitoring, etc.

Another area where DevOps practices can provide valuable data for continuous improvement is around monitoring and metrics. Capturing more data about how the software behaves in production - which features are used, which areas are slow, where users spend most of their time – allows you to improve the product or service you are delivering to your customers.

InfoQ: How can developers, testers and people in operations learn DevOps practices and find ways to work together more closely?

Sato: There are a lot of resources out there (my book being one of them) J Reading and watching talks are good ways to start learning, but I find it much better when you learn by doing. And starting where you are should present plenty of opportunities for introducing some DevOps practices. Here are some ideas to get them thinking:

  • Get everyone together in a room and draw the current process required to get a change to a single line of code deployed and running in production. How long does that take? How can you make that a non-event? How can you make that process run as fast as possible, without compromising on the quality?
  • What is your current process to deploy an emergency fix? Is it completely different than the process to deploy a “normal” release? Imagine how to make those a single process that’s both fast and reliable.

About the Book Author

Danilo Sato is a technologist with more than 14 years of industry experience. He works as a consultant for ThoughtWorks since 2008, acting in various roles such as: developer, trainer, architect, and coach. Currently, Danilo is a member of the Office of the CTO, and the global initiative lead for Data. He helps ThoughtWorks' clients adopt practices to reduce the time between having an idea, implementing it and running it in production using Cloud, DevOps and Continuous Delivery. Danilo is the author of “Devops in Practice: reliable and automated software delivery” and an international conference speaker having presented talks and workshops in conferences such as QConSP, RubyConfBr, AgileBrazil, Agile, and XP. He was also the founder of the Coding Dojo @ São Paulo.

Rate this Article

Adoption
Style

BT