Click here to monitor SSC
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in
Home       Members    Calendar    Who's On

Add to briefcase ««12

Deployment Failures Expand / Collapse
Posted Sunday, December 16, 2012 11:15 PM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, September 22, 2015 6:55 PM
Points: 47, Visits: 130
SanDroid (12/14/2012)
Eric M Russell (12/14/2012)
Database deployments have unique challenges like: altering or dropping/recreating schemas while preserving existing data, object dependencies, schema variations between development, QA, UAT, and production.
However, the most problematic issue is how to rollback to a previous pre-deployment state. Sure, you can wrap your schema alterations and row insert/update/deletes in a transaction and then ROLLBACK cleanly during deployment in the event of a runtime error. But what if the business requests a rollback the following day, hours after the users have been using the application? That's why the best approach in many situations is to analyze what specifically went wrong, and then deploy a followup fix.

+1000 agree with this. I have lived this many times. You deploy a release and find a use case nobody tested or was aware of that is causing issues in another section of code. Is it better to roll back to the previous version that can no longer work with the bussiness data, or fix the two lines of code and release a patch?
I vote for the patch every time.

Yes this is an extremely common thing for us too. Sometimes a "major" issue is found weeks after (e.g. during end of month reporting). Rollback is not an option and instead we rely on a patch and in worst case scenarios, repairing data if required (can use backups to help with this).
Post #1397098
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse