Grant Fritchey

21 July 2020

How do you make DevOps and automation work in the real world?

We talk a lot about DevOps at Redgate and how you can include the database when you’re automating your pipeline so that you can release faster while keeping your data safe. But what’s it like in the real world? Is it as easy as we make it sound, or do businesses struggle with it?

I was lucky enough to find out at a recent Redgate Summit session, where I was joined (via Zoom) by Stuart Ainsworth, Senior Manager at Jack Henry & Associates, and Chris Yates, Director of Republic Bank.

During the session, a colleague of mine, Dustin Abney, asked us questions about maintaining speed and quality with distributed teams. We ended up talking a lot about automating deployments and DevOps and I thought it would be good to share the insights that emerged. So here are Dustin’s questions, and an edited version of our answers.

What have you experienced recently in terms of customer demands on deployment speed?

The fun thing about my job at Redgate is that I get to see a lot of companies, from those with extremely immature development and deployment processes to those with more advanced ones. The one thing I can tell you is that everyone is accelerating the speed of their deployments and the reason is simple: we’re all being held to Amazon’s standards.

Everyone expects that level of service and speed so all businesses are struggling to keep up. And what you’re seeing is that successful companies are moving fast and the less successful companies aren’t. It’s clear as day.

Stuart agreed with me, but in a more measured way. “We’ve definitely seen a much greater awareness and competition pressuring us to get things done faster and bring new features to the market that do what they promise to do. There’s a lot of push to get new features out the door but there’s also a push for quality.”

Chris concurred and also brought up the need for testing. “From a business perspective, you’re always looking for new and innovative ways to continue to improve your development pipeline and move faster, and usually you see an increase in speed of around 16% to 17%. I’ve seen that in our own shop where we’ve done it, but you can’t forget the testing part. You end up moving at such a lightning-fast pace, testing becomes really important. It’s like a balancing act sometimes.”

Is there a difference in quality when you compare high performing DevOps organizations who have introduced automation with those who aren’t there yet?

Now for me, if you’re not automating testing and deployments, I guarantee your quality is not as good as people who are. There’s no way you’re going to be able to move as quickly and if you want to deliver higher quality faster, you absolutely have to be doing it.

You don’t have to do end-to-end testing, though, as Stuart pointed out: “It’s not about automating complete regression testing – you need to know what elements are important to the tests and focus only on those to accelerate the process.”

Chris also brought up measurement. “Another thing you should take into consideration is how you measure DevOps performance. Any high velocity organization is going to ask that question and I always see DevOps as a way of increasing the speed of deployments and decreasing risks. So when you say you’re going to implement it, you have to be able to add how you’re going to measure it and what benefits you’re getting from it.”

In terms of the current situation and the move to remote working, has the speed of deployments changed?

From a Redgate perspective, the interesting thing is that when we shifted to working at home, the emphasis was on people. People first. Our CEO was amazing, frankly. And the really interesting thing was that our development teams by and large didn’t miss a step. They’re releasing software as fast, if not maybe faster, than they were prior to all these switches, mainly because they already had processes in place for doing everything. Picking up the laptop and changing it to another location didn’t affect the process.

This isn’t just a Redgate thing, it’s a wider IT and DevOps thing, which was neatly summarized by Chris: “If you’re in IT, generally you’re able to work from anywhere in the world. So it wasn’t that big of an adjustment for us to just work remotely, and we’ve had groups where productivity has actually skyrocketed. We haven’t missed a step really from an IT perspective, and that goes hand-in-hand with our DevOps processes along with our regular release processes. I think a big part of that is because our culture is all about our people. DevOps is a cultural initiative, almost a way of life, and you just don’t get there overnight. It’s a shift that occurs over a period of time and once you hit your stride, you really see the benefits.”

As we start adapting to a new normal, do you expect any long-term changes to the way teams develop software or manage their data?

As much as you hear the ‘new normal’ phrase over and over again, I don’t believe it. I read a lot of history and there’s been many pandemics, global or otherwise, and what’s really interesting is that human beings kind of circle back around to places where they’re comfortable. We’re much more comfortable – and efficient – communicating face-to-face.

I suspect that while there are definitely going to be shifts because of everything going on, we’ll go back to something that resembles what we had before all of this. That’s the way human beings work.

Whatever that ends up looking like, Stuart brought up a fascinating observation about the way he’s seen software development changing: “What I’ve seen coming out of this move to working from home is that developers are getting really good at doing small things independently and then coming together to talk about them. It’s that cycle of breaking apart and coming back together, breaking apart and coming back together that’s working really well. At the same time, we’re also getting good at implementing the automation pieces that help orchestrate all of those small things. I predict that we’re going to see a rise in the role of Software Architects who say ‘You go build this, you go build this, you go build this’ to teams of developers and then help stitch all the pieces together in preparation for the next version release.”

What are the lessons you’ve learned on your journey to automation and DevOps?

From a personal perspective, I’ve seen DevOps initiatives fail more often than I’ve seen them succeed. That’s not down to tooling or automation, it’s because the business or the people, or both, didn’t make the commitment. Without a commitment to making it happen, you’re doomed to failure.

Chris agreed but added a more positive note. “You can’t be afraid to fail because you’re going to be stuck and not able to move forward. So don’t be paralyzed and don’t be afraid to make mistakes. You’ll end up looking back and saying ‘Why didn’t I do this sooner?’.”

Stuart also gave some really good advice. “The biggest thing I’ve learned is to start small. We started with a project that was contained within my team and we just did that over and over again and learned as we went. Then we took on a bigger project and started to rely on other teams’ inputs. That’s where negotiating with people becomes really important. You find one developer who’s interested and get them to help you with something and build on those conversations.

“Then it comes time for the ‘frienemy’ conversations – those with people who don’t really want to do DevOps. One of the things we’ve learned is that it’s got to be about them and the problem you’re going to solve for them. That’s how you get their buy-in. It’s not about saying how easy it is, it’s about explaining what they’ll get out of it, like giving more of their time back to them. You’ve got to be able to have those arguments and have a psychology in place to do it.”

How do you see DevOps evolving moving forward?

I thought this was the most telling question of the whole session because our answers reflected each of our experiences.

Stuart uses a complex suite of tools and does a lot of data integration work, so he focused on how to make Dev and Ops work even more closely together. “For me, the next part of the DevOps journey is going to be how we escalate the operational processes to the same level development has enjoyed for a while. How do we begin to phase in things like change control and auditing, but figure out how to do it faster with the same overhead and oversight we have now?”

Chris is responsible for data and architecture at a bank, and he brought up information security. “I think if we come back again next year, we’re going to have a completely different view of where we’re at now with DevOps. DevOps itself is going in lots of different directions and it will be interesting to see over the next six months to a year what advances we’ve made. I’d love to see some of the regulatory requirements we have to deal with incorporated into our processes to help with audits and things like that. I think infosec is going to be another area where it will be interesting to see how it becomes more involved with the process.”

And me? I think in the next two to five years no one is going to say DevOps ever again. We’ll remember it the way we think of waterfall. It’s not that we’re not going to be doing it – far from it. We’ll all be doing it.

We’ll be automating infrastructures, automating deployments, automating the whole process, and it’s all going to be about people. You don’t need a term for that. Everyone is starting to realize that if you’re not automating, you’re failing. It’s literally that simple. It’s just down to you to automate or fail, so automate.

If you’d like to learn more about how businesses in the real world are introducing database DevOps, join Grant Fritchey for another Redgate Summit session on July 22-23, where he’ll be joined by by Tobias Riley, Consultant, Contractor at The Data Crew and Joshua Higginbotham, Data Services Manager at Republic Bank.

For more information about how Database DevOps can help you deliver value faster while keeping data safe, visit Redgate’s Database DevOps resources page online.