Continuous Deployment - Continuous Integration - page 196

Labeling a build is as simple as performing a full build and assign-
ing an identification to it. For example, deploying a labeled version to
a QA environment should be as easy as typing the following:
ant -Dbuild.id=2_89.01 -Denvironment=qa deploy
What's interesting about automating a deployment like this is that
all of the other processes must be executed (compilation, database
integration, testing, inspection, etc.) before the deployment is exe-
cuted. Obviously, a compile is performed, but there are other key steps
in the process, including a successful database rebuild and successful
tests and inspections run. Moreover, there could be additional tests run
after a deployment.
Run All Tests
While some stages of development may only require running certain
groups of tests, before packaging a deployment build all tests must run
and pass. It's that simple. Run all of your automated tests, from unit
tests to functional tests. It can be done once on your build machine, but
an important part of predeployment testing is to run all tests on your
clean, reapplied environment, a clone of the targeted production envi-
ronment. It is important to make sure one more time that no environ-
mental issues will cause a failure or unintended performance. By
running all tests before promoting to the next stage, you develop more
confidence that you have working software . And even though we
firmly believe in the power and necessity of automation in all sorts of
processes, including testing, software is still a product which will be
used by humans and, therefore, still needs to be tested by humans.
Create Build Feedback Reports
Generating automated build feedback facilitates a common under-
standing of what exactly is in a build intended for release, including
the file differences in the build, the defects addressed, and the features