This editorial was originally published on Mar 17, 2015. It is being republished as Steve is traveling to SQL in the City - Austin.

I've been studying deployment ideas and technologies for quite some time now, but it's been a focus for the last year or two as my employer is interested in this area. I've been reading books and talking to people, comparing their experiences with my own. I've found that deployments for databases are much more complex than those for other software, but essentially there are two approaches that people choose: migrations and state based migrations based deployments.

Migrations based deployments are based on tracking each change to a database in a separate script and then executing each script, in order, on your production database. This is hard to do, requires discipline, and is what most people find difficult to do. Scripts get quite numerous, ordering is hard, and deployments become scary and largely unsuccessful without a lot of care. The scripts require tweaks and fixes to work efficiently, and you need smart DBAs and developers.

State based deployments are what many people try to use. They look at the state of production, the state of development, run some tool like SQL Compare, or a process, and determine what changes need to be made to production to get it to match development. There are variations, but this is the basis for how many people try to create a deployment process. It seems easier.

The problem is that at some point a state based deployment process won't work. It's actually impossible for a state based approach to work in all situations. Simple actions, like renames, can't be handled by examining two states. In order to properly manage changes, and keep your data intact and safe, you need to understand "what" happened during the process, not just the end result.

In many situations, state based deployments can work, and they can be used successfully, but there is always the possibility that you'll need to customize your state based approach to include some migrations scripting. Keep that in mind, and make sure that any process or tool you choose has that flexibility. If you understand you need to review and modify scripts at times, you should be successful.