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)
Continue reading on SirSQL.net.