Skip to content

Staging Deployments

November 30, 2012

Deployments are hard. We added Migration scripts in SQL Compare to help.

Software development can be a complicated dance. Most of us do not work for a software vendor and don’t have the strict requirements for our deployments when we control the client systems. That doesn’t mean it’s easier for us, especially as our environments grow more complex and the availability of our systems becomes more important. Application changes can become disconnected from the database changes, especially when the scope or scale of the change is large, which can present problems.

Making database changes can be challenging since we must ensure that our data is not lost as objects are altered. We have to ensure that any application functions that depend on a certain schema receive the data they need, without unnecessary errors. The timing of changes becomes more important in the database than in applications in many situations. This Friday I am curious how many of you decide to stage these changes in your environment. If you have dependent changes, I’m wondering if you might alter the database first and change the application in a later deployment.

How many of you deploy database changes before code changes?

By “before” I mean you deploy the database changes, possibly making some application changes, but there are other code changes deferred for a separate deployment at a later time. The use of views, defaults, optional parameters and more allow database changes to proceed without accompanying application changes. It may require a bit more work, but the database can potentially be changed during a less busy time, even if development or testing for the all the application changes is not complete.

The future will require more availability and stability from our systems as they become more essential to our organizations. Learning to update software, and databases, with minimal disruption is a skill that will set you apart in the future.

Steve Jones


The Voice of the DBA Podcasts

We publish three versions of the podcast each day for you to enjoy.

From → Editorial

2 Comments
  1. Nice post, not to provide a plug here but we utilize the Red Gate tools heavily for deploys with SQL Compare, on point to your topic though we actually stage it out. The database changes are first to go; pending on what the app requires for the deploy depends on when we push it out such as if services are independent they might be pushed out in parallel; if the app requires the database related changes then the app deploy will come after our database deploy.

    By the time it reaches us the source control that is set up is golden and the compare utilities make it extremely easy to push the database objects out.

  2. Plugs appreciated :)

    Good to hear that you stage things when appropriate. I think it’s a good way to get the DB moved and then have additional testing for the app if you can make the change in that way.

Comments are closed.

Follow

Get every new post delivered to your Inbox.

Join 4,636 other followers

%d bloggers like this: