Release Process Improvements
Posted
by wallismark
on Stack Overflow
See other posts from Stack Overflow
or by wallismark
Published on 2010-04-23T02:05:18Z
Indexed on
2010/04/23
2:23 UTC
Read the original article
Hit count: 418
The process of creating a new build and releasing it to production is a critical step in the SDLC but it is often left as an afterthought and varies greatly from one company to the next.
I'm hoping people will share improvements they have made to this process in their organisation so we can all takes steps to 'reduce the pain'.
So the question is, specify one painful/time consuming part of your release process and what did you do to improve it?
My example: at a previous employer all developers made database changes on one common development database. Then when it came to release time, we used Redgate's SQL Compare to generate a huge script from the differences between the Dev and QA databases.
This works reasonably well but the problems with this approach are:-
- ALL changes in the Dev database are included, some of which may still be 'works in progress'.
- Sometimes developers made conflicting changes (that were not noticed until the release was in production)
- It was a time consuming and manual process to create and validate the script (by validate I mean, try to weed out issues like problem 1 and 2).
- When there were problems with the script (eg the order in which things were run such as creating a record which relies on a foreign key record which is in the script but not yet run) it took time to 'tweak' it so it ran smoothly.
- It's not an ideal scenario for Continuous Integration.
So the solution was:-
- Enforce a policy of all changes to the database must be scripted.
- A naming convention was important for ensuring the correct running order of the scripts.
- Create/Use a tool to run the scripts at release time.
- Developers had their own copy of the database do develop against (so there was no more 'stepping on each others toes')
The next release after we started this process was much faster with fewer problems, indeed the only problems found were due to people 'breaking the rules', eg not creating a script.
Once the issues with releasing to QA were fixed, when it came time to release to production it was very smooth.
We applied a few other changes (like introducing CI) but this was the most significant, overall we reduced release time from around 3 hours down to a max of 10-15 minutes.
© Stack Overflow or respective owner