Implementing CI for databases V: Creating Octopus Deploy Projects

In this series, every component needed to do database push-button deployments is set up. From setting up the source control repository, preparing the build environment to configuring the deployment environment. All that’s left to do is to create an Octopus Project to enable real database push-button deployments. In this part I’m going to explain how.  Continue reading Implementing CI for databases V: Creating Octopus Deploy Projects

Implementing CI for databases IV: Configuring Octopus Deploy Environments

Now the Build Environment is configured to automatically create a new database build every time a change is checked in into source control, it’s time to configure the Deploy Environment so these builds can be deployed with the push of a button. Continue reading Implementing CI for databases IV: Configuring Octopus Deploy Environments

Implementing CI for databases III: Creating TeamCity Build Configurations for Database Builds

You want to deploy your SQL Server database changes with the push of a button and you prepared your Build & Deploy environments for that. The next step is to create a build configuration on your Continuous Integration server in a way that it automatically creates database builds when changes are committed to your source control system. In this post I’ll explain how I did that with our TeamCity CI Server.  Continue reading Implementing CI for databases III: Creating TeamCity Build Configurations for Database Builds

Implementing CI for databases II: Preparing the Build & Deploy Environments

You’ve got all the environments in place for building a database deployment pipeline, and now you want to prepare them to enable yourself to actually build one. What preparations do you have to do? You can start with preparing your Build & Deploy environments.  Continue reading Implementing CI for databases II: Preparing the Build & Deploy Environments

Implementing Continuous Integration for databases I: The Stage

You’ve convinced Management and your colleagues your company should implement Continuous Integration for databases, and now you are ready to actually set this up for your production databases. Where to start? How do you tackle this? In this series I’ll explain how I did it.  Continue reading Implementing Continuous Integration for databases I: The Stage

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

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

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

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