Information Technology Reference
In-Depth Information
Ultimately, having the capability to
undo
a deployment is an important
part of efficient development. There comes a time for many teams
when they need to rapidly replace new defective code with some previ-
ous release that worked better. By using build labeling and repository
labeling, this process only requires requesting the desired version.
For example, say that during a tight release schedule the QA team
receives build 89_3.04, which was to have fixed a number of high-
priority defects. After the deployment, however, QA quickly deter-
mines that this release candidate has a subtle yet showstopping defect
that prohibits further testing. By rapidly rolling back to the previous
build (89_3.03), QA doesn't necessarily lose precious testing cycles
and can continue to test the previous release and issue defects against it.
❑❑❑❑❑❑❑❑❑
Your project can benefit from continuously deploying working soft-
ware. While every application, platform, and target domain has unique
requirements, the process for effectively releasing working software at
any time and any place is largely dependent on six steps. Labeling a
repository version signifies a group of files as being related, while pro-
ducing a clean environment reduces assumptions about existing
assets that, when missing, can stump even the simplest of builds.
Generating a labeled build produces a named binary that can be
reported against, while ensuring that all tests run successfully can
help give you more confidence that the software is working as
intended. Build feedback reports facilitate a team's common under-
standing regarding features, defects, and requirements associated
with a binary. Lastly, having the capability to roll back a release means
that if something goes wrong, you can still provide users with the last
working version.
Ta b l e 8-1 summarizes the practices covered in this chapter.
