Matt Hilbert

4 November 2019

Redgate’s journey to DevOps

At Redgate, we research DevOps, write articles, whitepapers and other content about DevOps, and talk a lot about DevOps. We actively encourage our customers to introduce database DevOps too, using our portfolio of database development solutions.

But here’s the thing. We don’t do it to sell software. We do it because we believe in it.

For the last 20 years, Redgate has been on its own journey to DevOps. We started with one product (SQL Compare) developed by two people in 1999 and we’ve grown to a portfolio of over 30 products, offices in four countries, a worldwide roster of Partners, and 400 people.

On the way, we’ve also moved from the old-fashioned Waterfall method of software development, with big bang releases every six months, to DevOps. So far this year, for example, we’ve released 1,295 software updates and there’s a whole bunch more coming down the development pipeline.

We focus on Agile and Lean principles, and continuous improvement, and empower teams with the freedom to act, a clear purpose, and a drive to learn. That’s not just in software development – that’s everywhere. Our support, sales and marketing teams work in the same way too. DevOps is a good thing for everyone.

We didn’t just press a switch and start ‘doing’ DevOps, however. Instead, Redgate has been on a long journey to DevOps and we thought it would be good to share our learnings.

What is DevOps?

Let’s answer the big question first. Around 100 businesses joined Redgate at a recent SQL in the City Summit in London to learn how to improve their database development process. Some, like Aberdeen Standard Investments and Linney were already doing DevOps, but others were there to find out what it is.

At Redgate, we tend to answer the question by quoting Donovan Brown. Also called ‘The Man in the Black Shirt’, he’s the Principal Cloud Advocate Manager of the Methods and Practices Organization at Microsoft. Quite a mouthful, but he’s also a passionate believer in DevOps. He’s visited Redgate many times, appeared alongside us in webinars, spoken at SQL in the City LA, and his explanation of DevOps is often quoted because it’s short and sweet:

DevOps is the union of people, process, and products
to enable continuous delivery of value to our end users.

Quite simply, DevOps breaks down walls between development and operations. It streamlines and automates processes, and rather than aiming for big releases with long development cycles, it encourages frequent, smaller releases that deliver value to customers faster.

Let’s start with people

A basic requirement of DevOps is collaboration, cooperation and teamwork, both within teams and across teams. That sounds easy, but achieving it can depend on the type of organization you work for.

The reason lies in an academic paper written by Ron Westrum, an American sociologist, in 2004. In A typology of organisational cultures he outlined the three different kind of cultures that exist within organizations, and created what’s now known as the Three Cultures Model:

You may well have worked in an organization with a pathological culture, and you’re probably familiar with the by-the-book culture of bureaucratic organizations. Here, it’s difficult for DevOps to exist because the glue that’s required to link Dev and Ops just isn’t there. Sometimes, it’s actively discouraged.

A generative culture, on the other hand, is one that DevOps can thrive in because it’s centered around cooperation, teamwork and novelty. You may not be surprised to learn that Redgate has such a culture – and that’s not an accident. When Redgate was first founded by Neil Davidson and Simon Galbraith in 1999, they had three goals:

• To work together to do something they found personally fulfilling
• To create software that made a technical contribution to the market and to the working lives of users
• To build a company culture that represented their moral values and who they were as people – this was in reaction to having worked in places where the humanity of the organization’s employees was seen by their managers as an annoying inconvenience

That third goal has been central to the company and a major contributor to the success of Redgate.

Quite simply, people matter. Give them a results-driven culture that blames anyone who fails to deliver, or a bureaucratic one that forces everyone to follow a rulebook, and innovation will be crushed, ambition defeated.

Give them, instead, a culture that is open to new ideas, encourages cooperation and collaboration, and focuses on doing the right thing, not the easy thing, and good things happen. Because people feel part of the process rather than alien from it.

So even before DevOps was a ‘thing’, Redgate was encouraging the kind of culture that would welcome it.

Now let’s talk about processes

While Redgate had a culture that was favorable towards DevOps, introducing it was a different story. The software development teams were eager to move to the shorter development cycles and continuous iteration of development and testing that DevOps promotes, but new Agile processes and practices had to be adopted to make it happen.

The question was, which processes and practices? Scrums? Kanban boards? A3s? Standups? Burndown charts? The Deming Cycle? Monthly releases? Weekly releases? Pair programming? Mob programming? Extreme programming? Trunk-based development? Continuous delivery or continuous deployments?

As you can see, there are many aspects to Agile so the first job was to understand them and see which could – and should – be implemented at Redgate.

In 2008, the first project to use Scrum began at Redgate. The Agile technique breaks down work into goals that can be completed within a fixed time period of one month or two weeks. At the end of each of these sprints, the ideal is to have software ready to release.

That initial project has been followed by many, many more, and a whole variety of other techniques and methods have been tried, with varying levels of success. The result is that Redgate has moved from releasing every six months in 2011, to the point today where teams are releasing every two weeks and sometimes daily.

The journey has also changed direction many times, based on the latest thinking about DevOps. The 2018 Accelerate State of DevOps Report, for example, identified four key metrics that can be used to predict software delivery performance, and these are now used to rate Redgate’s own performance. By tracking deployment frequency, the lead time for changes, the change failure rate,  and the time to restore service when there is a failure, areas where improvements could be made can be identified.

The important point to note here is that Redgate is still on the DevOps journey, and the goal is to continuously improve processes and practices.

What about the products?

The third factor Donovan Brown mentioned in his description of DevOps was products. DevOps starts with people, then it introduces processes, and finally it brings in products or tools that can help in areas like testing, static code analysis, automation and deployments.

The development teams at Redgate have tried many tools and the main ones in use now are Visual Studio, Azure DevOps Server, Jenkins, GitHub, SonarQube and RayGun. They also use Redgate tools like SQL Compare, SQL Change Automation and Flyway so that the database can be included in DevOps as well.

If you’re exploring DevOps, the key message here is to find the tools that work for you and best fit in with the processes you’ve introduced. Try them, test them and see if they help or hinder your DevOps journey.

Where are you on your DevOps journey?

As you can see, we like DevOps at Redgate. We practice it as well as preach it and over the last ten years or so, we’ve used it to develop the products and solutions that help businesses (including our own) adopt database DevOps as well.

That said, if you’d like to know more about it, or if you have questions looking for answers, talk to us. We appear at conferences all around the world, and Redgate Advocates regularly speak at SQL events like SQL Saturday.

We also have a selection of DevOps whitepapers and case studies that may help you. Find them on our DevOps resources page.