Moving your database development, deployment and management into a DevOps methodology does involve choosing and implementing tools and tooling. Tools are a necessary aspect of DevOps because, one of the fundamentals of implementing a DevOps approach is automation. To automate, you need the right tools. However, tools and automation, while they represent a lot of work, are actually the easy part of the process of moving into DevOps. What’s the hard part?
Changing how you do things.
Change is Hard
One of the fundamental questions you need to learn when you start to implement a DevOps approach consists of a single word: Why. “We always manually run a script in staging prior to running it in production.” Well, why? Why can’t that be automated? Is there a reason that the script has to be run manually? You need to establish the purpose behind processes. This is because, far too often, the answer is, “Well, we’ve always done it that way.” Yeah, fine, but why did you do it that way. Too frequently, people don’t know the reason, yet, are resistant to introducing a change to the process.
Change is hard. Change is difficult. Change is scary. Change, and change alone, is the most difficult part of implementing DevOps into any company. Getting the development team to let the DBAs help with development at an early point in the process in order for the last steps, deployment into production, to work better is difficult because it entails change to how those development teams are used to doing things. Getting DBAs on board with the concepts behind “shift left” in support of more accurate development is a challenge because it means they’re surrendering some degree of control. Getting management to support all these efforts is a challenge because it entails shifting away from how things have been done.
I’ve been brought in to multiple organizations to look over their development and deployment processes because they recognized that they had roadblocks and bottlenecks that were preventing faster, safer delivery of the applications. Time and time again, I’ve outlined changes to the process, why it’s better, how it leads to improvements, and the incremental steps needed to deliver the changes. Yet, people will not implement these suggestions, not because they’re wrong, but because, they’ve always done the process one way and that way is now comfortable. Change is hard.
Implementing DevOps
I work for a tool vendor, Redgate Software. That means I want you to buy our software. However, the really important thing to me is not that you buy our software one time, but that you continue buying the upgrades, service contracts, and new tools that come along. How best can I ensure that you do this? By making darn sure that our software helps you. How can our software best help you implement DevOps? By you examining your processes and changing them, then picking and choosing how to employ our tools in support of that process.
I need you to understand why you’re doing what you’re doing within your development, deployment and management process first. I need you to answer the question, Why. Then, I need you to be open to changes that are going to be required. The last thing on the list should be you shelling out cash for my software. This is because, without the changes, and the willingness to change, the likelihood my software actually helps you is reduced. If my software doesn’t help you, you’re going to blame me, not the fact that you haven’t made the necessary changes to your process.
Tools Are Just Labor
After your organization commits itself to making necessary, studied, tested, validated, supported, changes to it’s process, then, you implement tools. As much as I say that the tools are easy, and Redgate tools are ever so easy, doesn’t mean that you’re not going to be doing work. You are. Further, as you implement the tools, you’re likely to spot other opportunities for process improvement through the use of the tools. That’s more work. It’s also more change.
Fortunately, there is tons of documentation supporting all sorts of process automation. I’ve even got a video how-to on using a combination of Redgate and TFS to fully automate a deployment process through the database. It’s just labor to set things up to support your automated deployments in the database.
Conclusion
Please, so that I can best support your efforts, focus first on your process. Go through and understand why you do the things you do. Eliminate or change any steps that are only defined by “We’ve always done it that way”. Get management on board and supporting your changes. Embrace the fact that you need to change in support of DevOps. Then, come and talk to me about the tools. I have some excellent ones to sell you and I know they’ll make your DevOps processes easier to manage.
Totally different set of tools, but I have a number of all-day seminars on Query Tuning Tools coming up. Find the one nearest to you and sign up:
For SQLSaturday Indianapolis (and my first time speaking in Indiana) on August 10, 2018. Please go here to sign up.
I’ll be at SQLSaturday Sioux Falls (and my first time speaking in South Dakota) on August 18, 2018. Please sign up here.
For SQLSaturday Oslo on August 31, 2018. Click here right now to register.
I’ll be at my local event too, SQLSaturday Boston, on September 21st. You can go here to register.
I’m going to be presenting at SQLSaturday Munich on October 26, 2018. Go here now to join the class.
For some additional reading on this topic, check out this article by a services provider, Jelvix.
I agree completely with asking why, it’s something I don’t do often enough. But I’m thrown by this statement: “If my software doesn’t help you, you’re going to blame me, not the fact that you haven’t made the necessary changes to your process.”
If I’ve asked why and understand the process, the tool may not be helpful, and it may not be beneficial for me to change my process just to fit the tool. Red-Gate is driving DevOps a certain way, which is great, but the cost to change to the Red-Gate model (not just licensing costs, but the cost of change you’ve mentioned above) may be more than the cost of staying where I am/going a different route.
OK, but are you saying that you’ve done your due diligence and realize that I can’t help you, so you don’t buy my software, in which case, I understand. Or, are you saying that you bought my software, and then realize that you’re not able to make the changes needed to implement it? If it’s that second thing, that’s my concern. I want you, or anyone, to succeed after buying my software. That’s why I want to emphasize the need to do commit to the changes first. If you can’t do those, again, either through acknowledgement that the organization just isn’t ready, or that our software just won’t support you properly (and we can support just about anything), then it’s OK.
I know we can do simply amazing stuff. We just can’t perform miracles.
I’m left wondering why. why move to the newest dev fad? I’ve been in this world since the days of the RAD revolution and I see these things come and go. Why not just work to have the smoothest, safest, most controlled process possible within your organization and quit coming up with names for it?
RAD, XTreme Programming, Agile, Dev Ops, if people would spend more time focusing on their business and less keeping up with all these fads we’d be better off.
But I suppose tool vendors need to sell software too.
I would argue that DevOps is not a fad at all. I tore the Gartner definition down to this:
An agile culture that better supports collaboration between people that uses automation and tooling in support of process.
I started working with dev teams back in 2005 (mind you, I started working in IT in 1998) to find a way to automate database deployments the same way they automated application deployments. We were doing what is now called DevOps, but we just thought of it as our job.
As I tried to define above, DevOps isn’t about tools (and yeah, I want to sell millions of tools, it’s how I get paid), it’s about process, culture and communication. The tools are the last thing on the ticket.
Successful organizations are using process automation, agile methodologies, and yeah, DevOps (in spirit if not in name), to be successful. I say let’s emulate the successful (as long as we’re not taking a cargo cult approach to it). Whether you say you’re doing DevOps or just your job, if we’re working within an agile culture that supports collaboration between people, the rest works itself out.
I have always said there is no such thing as easy. There is just hard and not hard. And the key determinant of not hard is familiarity. This is the underlying reason why change is hard.