How I set up a POC Database Deployment Pipeline for Continuous Integration, part III

Curious about how to do a push-button deployment of a database change? This is the last part of this 3-part series on how I previously setup a proof of concept (POC) Database Deployment Pipeline, and I’ll show how I configured Octopus Deploy to make it happen. Continue reading How I set up a POC Database Deployment Pipeline for Continuous Integration, part III

Upgrading to SQL Server 2014: Step 0 – Determining RPO/RTO

As a DBA, it is advisable to collaborate with your colleagues from the operations team. Especially when you are planning to upgrade to SQL Server 2014 and they are planning to buy new hardware for your new database servers. That is exactly what I recently did, and in this blog series I am going to explain and document the entire process of upgrading our databases from SQL Server 2005 to SQL Server 2014. In this first post I am going to talk about the Recovery Point Objective and Recovery Time Objective, because that’s where a project like this all starts. Continue reading Upgrading to SQL Server 2014: Step 0 – Determining RPO/RTO

How I set up a POC Database Deployment Pipeline for Continuous Integration, part II

Are your database deployments painful and are you looking for an example of how to do them safely and simply? Then read on.

In this post I’ll show you how I configured our Build server to enable Continuous Integration for Databases in our proof of concept (POC) database deployment pipeline and, more importantly, how easy it is. Continue reading How I set up a POC Database Deployment Pipeline for Continuous Integration, part II

Hi, I’m your NotCalledDBA. How can I help you?

I’m offering the following services:

  • Restoring your oops deletes
  • Tune the performance of your queries
  • Refresh your environments
  • Build a database deployment pipeline for our databases
  • Provide advise on how to develop databases
  • Help you to automate your tests
  • Help test our new hardware
  • Preconfigure a VM template with SQL Server, so you can instantly build a new development environment (automatically of course)

In the mean time I have set up: Continue reading Hi, I’m your NotCalledDBA. How can I help you?

How I set up a POC Database Deployment Pipeline for Continuous Integration, part I

To convince management, development, operations and quality assurance (QA) that we needed CI Continuous Integration for databases, I had to set up a proof of concept (POC). For this proof of concept I used the Bookstore database, which is the sample database used in Redgate’s SQL Source Control Basics book. I could have used any database, but since I was already using this database for learning SQL Source Control, I had it to hand. In this post, I’ll give a bit of context to the POC I built, explain a little about how I got buy-in, and then walk through the details of how I got the test database into source control. Continue reading How I set up a POC Database Deployment Pipeline for Continuous Integration, part I

DevOps DBA?

This week I had an interesting discussion with a colleague. I showed him this blog and he claimed there is no such thing as a DevOps DBA. According to him a DevOps team is a single team with different disciplines, which is responsible for delivering software and the systems they run on. They do the dev and the ops, and system engineers become obsolete this way. But, he argued, a DBA is different – it’s a specialist function, and hence doesn’t fit in a devops team.

I can agree on that, but do you need to be in a DevOps team to call yourself DevOps DBA? What is the definition of a DevOps DBA, anyway? If you search the Internet you’ll find a handful of vacancies for DevOps DBA Engineers (about 3500 results) and if you search for “SQL Server DevOps DBA”, you’ll find even less (about 750 results). It’s hard to find a definition for a DevOps DBA, which means it’s time to take a quick dive into the world of DevOps. Continue reading DevOps DBA?

Why we source controlled our databases

The initial reason we wanted our databases source controlled was to get rid of the conflicts arising because of the way we worked. To be specific, the way we worked was to manually create a change script and a rollback script for every change we made – for some deployments this meant we had to deploy dozens of scripts, all manually. Can you imagine the time it took for developers to handcraft each of those scripts, run them in a shared development environment, and then promote the changes to our test, acceptance and production environment? I’ll give you a clue – it wasn’t trivial. Continue reading Why we source controlled our databases