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.
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.
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.