Believe it or not I’m not actually talking about server documentation here (for an excellent post on that go read Colleen Morrow’s The Importance of a SQL Server Inventory).

I have spent the last 12 days dealing with a single production release. It is being considered a significant release, but to be honest it really isn’t. The biggest challenge has been to do with the way that the release documentation has been provided and the fashion in which the scripts have been built.

What I got

Here’s a brief example of a change request I’ve seen:

• Change Request:
  • Update database – products (this links to a Sharepoint page)
  • Use code from this location (links to a file share)
• Sharepoint page
  • Go to this location (but replace the middle part of the link with the link from the change request page)
  • Copy this subfolder to your machine
  • Follow the process on Sharepoint page 2 to deploy the code
  • Once Sharepoint page 2 is complete run script X
• Sharepoint page 2
  • run script 1
  • run script 2
  • run script 3

Pretty painful right? Now multiply that by 8 for each of the database code deployments that needed to be completed. No fun, no fun at all.

What do I want?

It’s going to be a work in progress but we’ll be working with this particular dev team to put together a unified document to simplify the release structure.

Here’s what I want to see:

• Change Request:
  • Update database – products – deployment instructions attached
• Attachment
  • Deploy script 1 (link to script)
  • Deploy script 2 (link to script)
  • Deploy script 3 (link to script)
  • Deploy script X (link to script)
  • Rollback script (link to script)

The difference?

Instead of having to reference several different Sharepoint locations in addition to a change control document I now have a single document, attached to the change, which clearly defines the process for the release, the order for scripts to be executed, a link to each of those scripts and the relevant rollback information.

It’s not something that I think is too out of line to provide, but I’ve found the folks who have been providing releases in this method are extremely resistant to change. I can understand that, but to be fair, they aren’t the ones under the gun trying to put something in to a production environment in a consistent and stable manner.

I’ve lots of fun meetings coming up to talk about this.

What about you?

How do you get your change control documentation? Is it something plainly written and easy to follow? Or do you have to have a degree in cryptography to get code in to production?