Ideally, system testing should be performed on releases, rather than on builds without the final packaging steps of a release. That way, when a particular release is deemed worthy of shipping to customers, the release process can use a known set of files to build the release. This also ensures that the installation software is tested, at least in the most common way that testers install the software.
When a build is converted to a release for internal testing, or an internal release is converted into a customer release, the following steps are commonly followed:
Obtain virgin copies of the correct files using the local SCM tool. The version of the product that uses these files has already been built and tested.
Set the release number and other build information, either in a file, a database, or on the command line.
Build the product for each platform.
Build the packages that are released to customers.
Update the release notes as part of the packages.
Retest the different packages prior to releasing them. Don't just check that the installer works—run as many of the unit and system tests as possible against the installed product.
Use the SCM tool to tag all of the files that are part of the release, including all automated tests and test results.
Archive all customer releases and any other important builds.
Automating the process of creating a release will reduce human error and speed up both regular customer releases and emergency fixes. There are some ...