Search code examples
build-processreleaserelease-managementsdlc

Release Process Improvements

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:-

  1. ALL changes in the Dev database are included, some of which may still be 'works in progress'.
  2. Sometimes developers made conflicting changes (that were not noticed until the release was in production)
  3. 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).
  4. 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.
  5. It's not an ideal scenario for Continuous Integration.

So the solution was:-

  1. Enforce a policy of all changes to the database must be scripted.
  2. A naming convention was important for ensuring the correct running order of the scripts.
  3. Create/Use a tool to run the scripts at release time.
  4. 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.

Solution

  • Automate your release process whereever possible.

    As others have hinted, use different levels of build "depth". For instance a developer build could make all binaries for runnning your product on the dev machine, directly from the repository while an installer build could assemble everything for installation on a new machine.

    This could include

    • binaries,
    • JAR/WAR archives,
    • default configuration files,
    • database scheme installation scripts,
    • database migration scripts,
    • OS configuration scripts,
    • man/hlp pages,
    • HTML documentation,
    • PDF documentation

    and so on. The installer build can stuff all this into an installable package (InstallShield, ZIP, RPM or whatever) and even build the CD ISOs for physical distribution.

    The output of the installer build is what is typically handed over to the test department. Whatever is not included in the installation package (patch on top of the installation...) is a bug. Challenge your devs to deliver a fault free installation procedure.