Life-Cycle Model allow you to create a reusable template that maps your organizational structure, giving you control over how a build is identified, the different stages a build must go through on its way to the end user, how artifacts are handled, and which clean-up policies are enforced.
A Life-Cycle Model consists of:
Cleanup Policy specifies when to delete information about old Build Lives and other tasks associated with the project.
Stamp Style Group creates common names for types of stamps.
Artifact Set is a grouping of related build products, such as the scripts used to populate a database, artwork for a video game, a CD ISO, or code library. Because most projects generate similar types of artifacts, the artifact set group holds the names of artifact sets for a type of project.
Status Group is a set of common names for statuses. 'Failed' and 'Successful' are default status names, but common other names might be 'Deployed to Test', 'Deployed to Production', 'Retired', 'Passed Function Testing' or 'Approved'.
| A typical life-cycle (or pipeline) would be DEV > QA > PROD: a build starts out in development, is deployed to quality assurance for testing, and then finally sent to production for release. You would configure the Life-Cycle Model to apply a new status when a build is sent to QA, and one when the build is sent to PROD. Likewise, a stamp style (essentially a build identifier) can be applied to each build that corresponds to the status. This enables you to know exactly which build is in which environment because the status and stamp are recorded on the Dashboard. See Using Life-Cycle Models for more. |