Blog Post

Monday Coffee: Database Deployments

,

I’ve always been particularly cautious when it comes to deploying code to databases, some would say overly cautious.

Because of this I’ve always performed manual deployments. Checking the code, testing the code and then manually running it in production. I’m responsible for the availability, resilience and performance of these databases so I should be the one to deploy to them, right?

I think this is a mindset that a lot of DBAs have and in my opinion, completely justified. I don’t want to be woken up in the middle of the night because something’s been released to Production in my absence and it’s caused issues.

However over the last few months I have seen the benefits of continuous integration & continuous deployment so I have been looking at ways to automate our database deployments. We use Octopus Deploy at my company so a database deployment process has been built within that.

The tests we’ve done are really promising and last week we started deploying to our Staging environment. If all goes well we’ll be moving to Production soon.

I’m still a little paranoid that something will go wrong if I’m honest. Because of that the database deployments are separate from the app deployments and I’ll be performing them (for now). We have a really good code review process in place so I highly doubt anything will go wrong but it’s just my nature to take changes like this slowly. Validate each step and move onto the next, proving that what you’re doing is working correctly.

The end game here is to integrate the database deployments with the app deployments and have one person performing them. Specialists (like myself) would only be called upon to perform code reviews and resolve any (hopefully none) issues.

I’m off to go and see if we have any Staging deployments to be performed ??

Have a good week!

Rate

You rated this post out of 5. Change rating

Share

Share

Rate

You rated this post out of 5. Change rating