Sam Stewart

3 July 2020

1 Comment

How to stop standardization being a stumbling block in database DevOps

Updated July 2020

More and more enterprises are seeing the merit of introducing DevOps to speed up application and database development and deliver value into hands of their customers faster. The collaboration and cooperation it encourages typically reduces errors, cuts down delays and removes the pain from deployments.

That’s the good news. The downside is that standardizing the tech stack and processes involved in a manner that is scalable is the point at which many efforts fail. I’ve talked to a lot of customers about this and the reasons vary from “We’re not ready for it yet”, to “We just need to agree on a few things”.

I like the way Alanna Brown sums it up on her blog post for the configuration management company, Puppet: “Standardization is always a sticky topic because everyone recognizes the value of standardization, but often, no one person in the organization really has the power to enforce the standards.”

As one of the authors of Puppet’s State of DevOps Report, Alanna Brown has a lot of knowledge about the subject. The Report introduced what the authors call the five stages of DevOps evolution, and it’s the best model I’ve seen of how to introduce DevOps.

Rather than presenting the stages as a logical, linear set of arrows moving from left to right, they’re shown more as a journey that enterprises embark on. There are no timescales or targets – instead, the stages break down the journey into logical, straightforward steps that enterprises can take when they’re ready to.

Interestingly, ‘Standardize and reduce variability’ is shown as the second stage in the model and Alanna Brown also mentions in her blog post that in meetings with enterprises about how to introduce DevOps, the majority are stuck somewhere between stage 1 and stage 2.

So what do you do if you, like them, are also stuck?

Build the foundation for DevOps and database DevOps

The initial step, building the foundation, is covered in Puppet’s report but it’s not included in the five stages model, and the report authors actually call it ‘Stage 0’. I think they’ve left it out of the model because it’s more of a mindset thing, and I also think it’s one of the real reasons the DevOps journey can fail at the standardization stage – enterprises try to run before they can walk.

It comes down to the culture that exists in an enterprise. The foundation of any DevOps initiative starts with a growing understanding that collaboration and the sharing of ideas, metrics, knowledge, processes and technologies are good. So rather than different teams working in different ways to test and deploy application and database changes, the same patterns start to emerge across teams. Similarly, when one team discovers a better way of working, other teams also adopt it. Competition and rivalry is replaced instead by trust and a shared approach.

I include the database here, by the way, because many application developers are also now responsible for database development. If you don’t include database DevOps alongside DevOps for the application, the database remains a drag on the whole software development process.

Normalize the technology stack

The initial mindset and culture approach might be seen by some as a bit woolly, but the benefits start to be gained when enterprises move on to the first practical stage of DevOps evolution. This is the point when the tools, solutions and processes in place are reconsidered.

IT teams in enterprises that have not yet adopted DevOps often have varying approaches to software development, for example, and there may well be a range of legacy tools and solutions in place that are rarely used or only used by a limited number of people. The goal here is to eliminate redundant systems and build on a standard set of technologies that are scalable.

A great way to encourage this is to introduce version control, within and across teams, both for the application and database code. By committing code changes to a shared repository, often at the end of each working day, a single source of truth is maintained, cooperation and collaboration is encouraged, and siloed development practices begin to disappear.

Another is to encourage teams to code in the same style. This applies to database code in particular, which can be written in many different ways and can cause confusion when lots of people are working on the same database.

A tool like Redgate SQL Prompt, which I mention because it’s the industry-standard for helping to code in T-SQL, lets teams write and format SQL effortlessly in their own style – and then switch to the company-wide style in one click. It also highlights errors in code as it is written, and provides suggestions to improve it, which reduces mistakes and helps everyone conform to the same coding standards.

Standardize in a small way first

With a more open culture in place and a streamlined technology stack, standardization becomes a lot easier. You might want to reduce the number of operating systems to one or one OS family, for example, standardize on one database, and introduce the same toolsets across teams.

You should also think about using the same infrastructure for both application and database development. If you use Team Foundation Server, Subversion or Git, for example, for version controlling your application code, then make sure the database version control solution you introduce plugs into and integrates with it.

That way, you get more value out of your existing infrastructure, while being able to do more with it. Maintenance chores such as updates and patches will be minimized, the complexity of the systems will reduce, and teams can start to apply consistent management and deployment patterns everywhere.

But start small. The issue I mentioned earlier – no one having the power to enforce standards – is likely to remain, so the key is to introduce the new approach to one team or one project first, demonstrate that it works, and then roll out the same tools and patterns across other teams.

Take the next steps in your own time

Any enterprise which establishes a more collaborative culture, streamlines the technology stack, standardizes tools and practices like version control, and introduces database DevOps as well as application DevOps will see immediate benefits. Errors typically reduce, teams are happier and, because people are working in the same way, using the same toolset, it’s easier to introduce new team members and move teams around.

It also opens the door to the third stage in DevOps evolution, expanding DevOps practices. With version control in place, enterprises can introduce a continuous integration process to automatically test changes, for example.

There’s no hard and fast rule about the time-frame necessary to begin this stage or the following stages. The important point is that once you’re over the stumbling block of standardization, you can then continue your DevOps evolution at your own pace.

For more information about how Redgate can help standardize team-based development with database DevOps, visit the Redgate Solutions page online, or connect with me on LinkedIn.

You can also find out more about laying the foundations for standardized database development in this Redgate blog post.