Continuous Delivery Decision Points: Getting Software Safely into Production
Consulting manager Kelly Looney is speaking this week at DevOps Days Detroit. We sat down with him to learn more about his session, and the evolving focus of DevOps that he and others have spotted.
Noel: You’ve said that DevOps is evolving from focusing on build automation to full-on continuous delivery. What’s causing that evolution? Is it seeing enterprises reach—or get closer to—continuous delivery through DevOps?
Kelly: I think we have a pretty good handle and a lot of good technology that helps us automate builds through deployment, from Ant/Maven, Puppet, Ansible, Chef, and Salt, using repositories from Git to Artifactory. But automating that stuff does not make much difference if you are not delivering more often, and that is what it is all about. Small changes happening with great frequency is the future.
Continuous delivery is not the same thing as DevOps, but the two concepts tend to go hand in hand. Put together, they are a big part of the definition of modern development.
Noel: In your DevOpsDays Detroit session abstract you say, “Too many organizations approach continuous delivery by automating the wrong things and just increasing the amount of (often poor quality) code they have to maintain.” What are the wrong things to automate, and why has that happened in so many organizations?
Kelly: Well, it’s OK to automate whatever you can, just bear in mind that your automations become a part of your new production code base. Throwing low-quality code in there, just because you can, may not help you. The key point I am making is that you want to carefully craft the precise tests you need to get code to production, because you will be running those thousands or even millions of times. Your delivery pipelines are a truly strategic project.
Noel: I got a sneak peak at your slides for your session, and I noticed that you’re going to dive into the culture required for DevOps and continuous delivery to work. You list, “Are teams empowered to deliver what’s needed to meet your goals?” as an important question to ask when looking for organizational issues or blockers to success. What empowers dev/test/ops teams looking to move to DevOps?
Kelly: Empowered means responsible and with the ability to make decisions. Too many organizations have developed into mazes of “gates” which are groups (also known as silos) that are empowered to say “no” to putting something into production. With enough of those gates, organizations tend to simply freeze up.
Also, when a development group isn’t responsible for security, they won’t necessarily think about it. With “real” DevOps, teams are responsible for security and scale, and other teams with expertise in those things act as consultants rather than gates. The team creates a product and they stand behind all of it.
If you’re attending DevOpsDays Detroit, don’t miss Kelly’s session! And if you can’t make it, check out some of Kelly’s other work in our new content series: Scaling Modern Software Delivery!