One of the more interesting aspects of my job is talking about building software with customers. As I do more of this over time, the discussion have changed from "what is DevOps?" to "how do we get started in DevOps" to "how do we improve our DevOps process?" These days so many customers have bought into some aspects of DevOps that the last one is quite common. There are still a number of companies trying to get started with DevOps in some way, but very few people I speak with have no idea of what DevOps is or how why it can improve your company.

Of course, I'm not sure there's a great standard definition of DevOps. I often lean towards Gene Kim's Three Ways or Microsoft's broad view of the principles. Ultimately, most of the practical things that I find myself discussing are how to smooth the process of integrating code from developers and getting it transferred to production. Everyone wants this to go smoother, with mistakes caught earlier, and with compliance with whatever internal rules, regulatory mandates, and customer demands exist.

Grant had an interesting conversation with a few customers recently and wrote a blog about the conversation. There are a few items that resonate with me, and things that I like to emphasize to customers. The experiences from Stuart and Chris are common in any journey to improve your software process.

People need to test and measure. While testing has gained traction in the application development world, it's still fairly new to database people. However, as people try to reduce mistakes and problems, often from simple issues, they adopt more testing. They also start to realize that having instrumentation to help measure the impact of changes is important to learn what to test and watch out for.

Starting small is important as well. While there are many, many commonalities in all my customers, the way they solve these with their teammates, and the order in which they solve them, varies. Even if you were to end up with the same VCS, build process and deployment script as someone else, the journey will be different. The challenges from internal people and processes, the evolution of habits in your team with vary. You need to find your own path.

So start small, with a few people, let them learn and then teach others. Let them build up knowledge, habits, and skills that others can adopt. That's how most things work in the world. A few people discover something and then many follow their footsteps. If you want to build a better software process, find someone to start doing it. When they find something that works, the rest of the organization can stand on their shoulders.