Tag: DevOps

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.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

I’ve been writing, talking, and practicing DevOps for nearly 20 years. It wasn’t called DevOps back then, but in the early part of this millennium, I worked in a software team that embodied many of the three ways of DevOps.  We made small changes, we worked rapidly in short cycles, we adapted to our business needs, and we released often.

And we included the database.

At the time, this was a small team of about 15, and I had good control of the database processes, able to influence, debate, and demand our developers improve their skills regularly. We didn’t think about the database as anything more than one more challenge to overcome in order to build and release our software rapidly. Others feel that way as well and the ACM notes that a SQL database is no excuse to avoid DevOps.

This articles covers many of the things I’ve been preaching for some time. We use automation, we adopt good techniques, we instill discipline in our work, and we continuously improve. The article provides a few techniques for using deploying database changes. I do think some of these are good ideas, but as with many things, the devil is in the details. This is a high level look at what you want to accomplish, but the actual mechanism for making changes will vary, depending on your environment.

My employer is constantly searching for ways to improve database development, and we follow many of these techniques in principle. We recognize that testing and deploying changes needs to be easier and more reliable. As we build solutions, I think we’ve helped customers in many ways, however, my fellow advocates and I continue to preach a few things not in the article.

First, we need to continue to improve our code skills, which include data modeling. Moving faster doesn’t mean we get to shortcut good design principles. Second, everyone working on software touching the database needs to work closely together. The data is the most important part of this process, and we can’t afford to let anything happen to it.

I implore you to become better code writers, better software developers, and better team players. I also encourage you to look at DevOps as a set of principles, not as something you buy or install. Like much of life, adopting DevOps is a journey, just like your work with SQL. I’m sure that journey isn’t complete.

Steve Jones

Note: Podcasts paused this week as I have construction taking place at the house and nowhere to record.

I’ve worked in a a couple very high performing organizations that adapted to changing conditions and built software well. I’ve worked in more poorly performing organizations that struggled to release updates and patches, causing tremendous stress for the IT staff.  DevOps is designed to help improve our software delivery and quality, if you work on improvement in many areas.

I saw a post on LinkedIn, from the Chief Architect at HSBC bank. This was interesting to me because I see HSBC ads constantly when I travel to the UK. They’re the 7th largest bank in the world and was founded in 1865. If ever there was an organization with lots of legacy everything, this is it. They have every reason to do what they’ve been doing for years, since it’s worked out well.

The post notes that Jez Humble, well known DevOps author and co-founder of DORA, came to talk to them about software delivery and DevOps. For the author, the highlight of the day was the CIO giving this challenge: “… setting every team the goal to double, half and quarter every year: double the frequency of releases, half the number of low impact incidents, and quarter the number of high impact incidents.”

That’s an ambitious goal, and as the post notes, this results in exponential improvement year over year if the team can achieve this. I think there is likely some limit to this, based on team size and application complexity, but certainly when you’re going from a mid range performing software development group, this isn’t bad.

I like that this goal was set not just to increase deployments, but to also prevent incidents. I think too many managers look at speed as the goal, without requiring quality to improve. This goal doesn’t quite address this, unless the impact incidents include bugs and poor performing software. It can be easy to limit incidents to downtime from deployments, and not necessarily the use of software.

The hands off management of this approach is good as well. Not specifying how this gets done. Leave it to the technologists to get this done and hold each other accountable. With that kind of support from management, I’d hope most professionals would step up, improve process and quality, and take pride in their work. It seems to have worked as HSBC, as they’ve been written up a few times in their DevOps approach to IT. I think it can work anywhere with the right management approach.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.