This week there was an interesting article on DevOps and Ancestry.com's DevOps process. They are a fairly large enterprise, with 70+ teams that need to deploy code on a regular basis. As they've grown, there was some concern over each team learning how to best build their software pipeline. While they shared knowledge with each other, they had a diverse set of practices for deploying code. As a result, even though each team had a low chance of deployment failure, across 70 teams, that's a significant chance of a deployment failure, especially when most teams could deploy daily.

They changed in a way that I've heard about in many companies. They started to coordinate the tooling and limit the number of ways people could deploy. The teams can still deploy code independently, without a large coordinated change review process, but by adhering to a standard process that reduces the chance of a failure for deployments. Their result: zero deployment-related outages for the first quarter.

They have allowed teams to move have their own schedules, working on separate work on the website, which sounds great. Teams own all their own quality checks, and can deploy whenever they want to release code. All of this is great for velocity and feature delivery, but what about quality and shared services? There is a note that teams are accountable and they have lots of quality checks, but is that enough?

One of the main problems I see with DevOps is that many organizations still have an "Ops" team that runs the production infrastructure. Even the large DevOps success stories, like Google, have an Ops team. For those stories, Dev still own the early support for their services until they mature. At some orgs, Devs own their code support always. However, in many smaller companies adopting DevOps, they forget this part. They don't ensure developers have to respond when their code fails to perform. That's important if quality is going to be a priority.

The second thing this article, and many others, fail to discuss are shared services. There are certainly times when there is an API, or a database table that multiple teams and services have to access. What works well with 10 queries a second might fail when it's 10,000 queries a second. Who manages this? Who arbitrates competing needs or requests? Who deals with scale, which is often a part of quality? These are often some of the critical items in your architecture that need debate and resolution.

DevOps is a great philosophy for building software, but it isn't magic. Your developers aren't automatically better code writers, and many of the issues you had with teams working together aren't solved by buying tools. Management needs to support, and adhere to the philosophy of looking at the entire system, getting feedback, and learning from that feedback. Too often we deploy fast without adding additional quality checks, or without getting the culture to change and have developers own more than just the building of features. They also need to own the support later.