Section 9.7. After the Release


9.7. After the Release

Once a release has shipped and the project team has celebrated and been given suitable mementos, stock options, cash bonuses, and vacations in Hawaii, what comes next? If it was Version 1.0 and all goes well, then more people will be using the release than any beta version, so they will probably be finding more bugs. You may want to plan early for a 1.1 patch release soon after your 1.0 release datesuch are the vicissitudes of producing software.

Even if you have confidence that you have recorded everything necessary using an SCM tool, most people still prefer to preserve the actual source tree that was used to produce the release. This is partly a defensive move in case the SCM tool fails in some way, but it also helps you cope with unforeseen questions about the build later on (for example, "Was file A built before file B?").

The first step in preserving the build is to make the files read-only. One way to do this is to change the file permissions. Another way is to copy the files to a CD or DVD and then make that copy available online when requested. rsync is a standard Unix tool that can create a mirror image of the files on another machine for backups. Norton Ghost or the open source g4u are useful for preserving the entire contents of a hard disk when parts of the environment are not being managed by an SCM tool.

It's a good idea to create a build-preservation policy, clearly summarized somewhere public. This will avoid making one up on the spot when you start to run out of space to store the releases. (This is also discussed in Section 10.5.) I recommend keeping all customer releases and internal releases that had bugs filed against them available, and deleting all other releases older than a few weeks or months. The reasoning for removing internal releases that have no bugs is that it's unlikely that they will ever have any bugs. Enough generated files should be kept with each release to permit the use of debuggers. If non-debug versions are released to customers, then keeping both the non-debug and debug versions of the build is helpful for this.

Another task that may be necessary after a release is to prepare the source code and development environment to be placed in escrow. This is to protect customers in the event that your company goes out of business, in which case the source code to the product is released to them so that they can maintain it as they feel the need to.



Practical Development Environments
Practical Development Environments
ISBN: 0596007965
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net