In preparation for my upcoming DevOps training days (see the bottom of this post for details) and for some articles I’m working on, I’ve been building all new automation processes for database deployments. In the past, I’ve been using a fairly simple (and far too simplistic) example to do most of my demos. I haven’t built a full process in a little while.
OH MY GOD!!! IT’S PAINFUL!!!!!
Automation Ain’t Easy
The easy part of getting your DevOps done is the tooling. I say that all the time because it’s true. The hard part is changing your organizations culture to support the level of communication necessary for a successful DevOps implementation.
However, easy by comparison doesn’t mean just simply easy. There’s a lot of work involved and making mistakes early in the process has repercussions for every later step.
For example, where do your put your code?
Yeah, yeah, I know. Source control. I mean, where in source control do you put the code? What do you call the project and solution? Is it in git, github, Azure, or somewhere else? Choose wisely because every single step of automation you set up after this will be completely dependent on that first choice. Further, putting in github, or example, has repercussions for how you implement automation in Azure DevOps Pipelines.
So it’s not just a question of picking a tool, push some buttons, ta-da, we’re doing DevOps. Every choice needs to be planned out and thought through.
YAML Should Be YAMFSALML
Get a space wrong. Yes, a space. You’ll be in pain. That’s why we should call this: Yet Another Muther F****** Stupid A**ed Markup Language. Although I supposed that’s harder to say.
Regardless, Yet Another Markup Language, YAML, was created because all the other markup languages are awful. Guess what. So is YAML. Maybe the UN needs to get involved and we should have international treaties that outlaw cruel and unusual punishment of developers through the introduction of Yet Another Another Markup Language, YAAML.
Seriously, there’s no need for any more of these. Every one of them stinks and every solution just breaks things further.
Automation Is Working. Now What?
Once you’ve waded through the horror that is YAML. You’ve rebuilt your source control system three times. You found out that you didn’t pick the right place to do your test builds, so you had to completely rebuild that. You’re seeing a full blown, fully automated, build and release of your database.
YAY!
Are we done? Oh no. Not even close. You’ve accomplished a set of tests just be doing this process. However, now we need to implement more testing. All the testing. So, time to spend the next six weeks writing tests, right?
NO!
Instead, we approach the tests one at a time. You can’t possible get them all written. Plus, you don’t know for certain what tests you need yet. So, you have to create tests as problems arise. Further, and this is tricky, you have to figure out exactly where in the process you do which kind of testing.
Like every other step in DevOps, one step at a time. Small chunks. Iterative approaches. If all that sounds like DevOps itself, DING DING DING. Winner.
Exactly.
Are We Done?
So now there are tests, are we done? I don’t know. Who are the failures being sent to? Have we built reporting and dashboards for the rest of the team? Is this integrated with the application? Wait, what? We didn’t integrate our source control with the application’s source control. Back to square one… again…
You get the picture.
Yes, most of the work to implement DevOps is about communication. That’s a fact. However, automation is going to be a ton of work. The good news is, it’s rewarding as heck. The bad news is, it’s a ton of work. However, approach it the way you approach the rest of development and deployment. Do small, incremental, steps. Validate each step. Move on to the next.
And no. We’re not done. We’re never done. New development is going on. New tests have to be built. Software upgrades. Hardware upgrades. Process changes. It doesn’t stop or slow down.
I love it!
If you want to share the love (and a little knowledge), here are a couple of opportunities:
SQLSaturday Indianapolis Precon, Friday August 16th, 2019. Click here now to register.
SQLSaturday Oslo Precon, Friday August 30th, 2019. Click here to register.
Sadly it looks like the truth. Well done Grant you managed to scare me. On the hind-side it will helps me and I hope others too to set the right expectations and not to rush into it.
Getting a full-blown automated deployment is worth every bit of pain. However, just knowing there will be pain going in is the best bit of knowledge.
Rebranding from ScaryDBA to ScaringDBA.
[…] by /u/ScaryDBA [link] […]
Good points on this. I think having any sort of source control helps – just to make sure you don’t lose your code that works. However, if you change, you need to change all of the methods used to pull the correct branch(es). If you get to the point where you can build given versions and publish/deploy them to some location set in a variable, you’re in a really good place.
Ideally, you’re using some tool such as Jenkins/Octopus/GOCD/etc. that handles the interface w/ your version control system to take that burden away a little bit, but the fun of handling variables, security, and all of that is a big chore.
But man – once you get it working, life is much easier. I still remember going from literally all night releases down to “we’re pushing a bugfix in 5 minutes, we’ll be done 30s after that”. Life got so much better. The worst we had to deal with on a regular basis was having to run a long-running DB change – new index, updating tables, moving data. We had to plan ahead for those, but most other changes just went out with no issue.
No arguments from me. Pretty much lines up with my experiences.
[…] Grant Fritchey takes us through some of the baby steps in getting started with DevOps: […]