Database Deployments with Automatic Rollbacks, part V: Summary of the Series

This post is part of a series on deploying database updates with automatic rollbacks using EF Core Migrations and Octopus Deploy. In this part, we’ll sum up the deployment process we’ve created, and wrap up the series.

All posts in the series:

Part I: Where We Are, and Where We Want To Be
Part II: Packaging the Database Updates
Part III: Deploying the Database Updates
Part IV: Adding Automatic Rollback of Application Services
Part V: Summary of the Series (this post)

 

All the scripts in this series are available in this gist.

Where We Came From

When we started this series, we had a deployment pipeline for our application binaries, but database upgrades were still a hassle. As a consequence, we weren’t really able to deliver continuously, even though we had the ambition.

The New Deployment Process

With our changes to the deployment process as outlined in this series, we now have a process that looks like this instead:

Most of these steps, we’ve defined in this series; the remaining ones are very simple (and in no way required to get the database deployment scheme up and running).

With this in place, deploying is as simple as pushing a button, and in case of a failure we automatically restore a good known state. This lets us figure out what went wrong and fix it with less stress – the system is up while we’re doing it.

Hopefully, this article series can help you get there too. Good luck, and happy deploying!

Leave a Reply