Automated Database Deployments have been a huge help with our deployment process. I work on a team responsible for a database who has over 3000 stored procedures and 400 tables. The database was different between all environments. In the past, on any given deployment at least one schema change would be missed leading to a frantic emergency deployment. Since my team has adopted automated database deployments those issues have dropped to almost zero. Deploying database changes are almost as easy as deploying code.
Recently I helped define the Automated Database Deployment Process for Farm Credit Services of America. It was a lot of fun getting all of this working. I got to meet some of the folks over at Redgate and they have been very helpful. They even helped us in the initial stages of defining our process.
The tooling we use is Redgate SQL Source Control for database change management. Visual Studio Team Services runs Redgate the DLM Automation Suite to build NuGet deployment packages. And Octopus Deploy takes those NuGet deployment packages and pushes them to the database servers using Redgate's DLM Automation Suite as well.
Redgate already has excellent documentation for Source Control and DLM Automation Suite. The goal of this series is to not rewrite the documentation already provided by Redgate. Instead, the goal of this series is to provide a point of view from someone who implemented their tools and helped roll it out to other development teams.
Disclaimer: I am in no way affiliated with Redgate, nor do I speak for them. I just really like their tools. And I want to help the community.
- Database and Continuous Delivery
- Build Once, Deploy Anywhere
- Getting Buy-in
- Redgate SQL Source Control
- Redgate DLM Automation Suite
- Using Redgate, Octopus Deploy, and Gitflow for Continuous Delivery
- Rollbacks and Automated Database Deployments
- How Redgate helped our Database Lifecycle Management Process