Alex Rivera | Logout

Release Process Improvements

Asked 2010-04-23T02:05:18.537
13

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

build-process release release-management sdlc
Edit
Report

2 Answers

3

We were already using TeamCity (an excellent continuous integration tool) to do our builds, which included unit tests. There were three big improvements were mentioning:

1) Install kit and one-click UAT deployments

We packaged our app as an install kit using NSIS (not an MSI, which was so much more complicated and unnecessary for our needs). This install kit did everything necessary, like stop IIS, copy the files, put configuration files in the right places, restart IIS, etc. We then created a TeamCity build configuration which ran that install kit remotely on the test server using psexec.

This allowed our testers to do UAT deployments themselves, as long as they didn't contain database changes - but those were much rarer than code changes.

Production deployments were, of course, more involved and we couldn't automate them this much, but we still used the same install kit, which helped to ensure consistency between UAT and production. If anything was missing or not copied to the right place it was usually picked up in UAT.

2) Automating database deployments

Deploying database changes was a big problem as well. We were already scripting all DB changes, but there were still problems in knowing which scripts were already run and which still needed to be run and in what order. We looked at several tools for this, but ended up rolling our own.

DB scripts were organised in a directory structure by the release number. In addition to the scripts developers were required to add the filename of a script to a text file, one filename per line, which specified the correct order. We wrote a command-line tool which processed this file and executed

answered 2010-05-05T00:21:04.757
1

Agree with previous comments.

Here is what has evolved where I work. This current process has eliminated the 'gotchas' that you've described in your question.

We use ant to pull code from svn (by tag version) and pull in dependencies and build the project (and at times, also to deploy).

Same ant script (passing params) is used for each env (dev, integration, test, prod).

Project process

  • Capturing requirements as user 'stories' (helps avoid quibbling over an interpretation of a requirement, when phrased as a meaningful user interaction with the product)
  • following an Agile principles so that each iteration of the project (2 wks) results in demo of current functionality and a releasable, if limited, product
  • manage release stories throughout the project to understand what is in and out of scope (and prevent confusion abut last minute fixes)
  • (repeat of previous response) Code freeze, then only test (no added features)

Dev process

  • unit tests
  • code checkins
  • scheduled automated builds (cruise control, for example)
  • complete a build/deploy to an integration environment, and runs smoke test
  • tag the code and communicate to team (for testing and release planning)

Test process

  • functional testing (selenium, for example)
  • executing test plans and functional scenarios

One person manages the release process, and ensures everyone complies. Additionally all releases are reviewed a week before launch. Releases are only approved if there are:

Release Process

  • Approve release for a specific date/time
  • Review release/rollback plan
  • run ant with 'production deployment' parameter
  • execute DB tasks (if any) (also, these scripts can be version and tagged for production)
  • execute other
answered 2010-05-05T02:58:48.437

Your Answer