Lifecycles contain an ordered list of phases. Each phase represents a team's work on the release applications. For example, the default lifecycle contains phases for development work, various testing phases, and a phase for production deployment of the applications. You can customize the phases in a lifecycle to match how your applications move from the beginning to the end of the release cycle.
Each phase can have one or more gates. Gates represent a requirement that must be met before an application can move to the next phase. Each gate has a target status; when the application has that status, the application can pass through the gate. For example, an application might need to pass certain tests or receive an approval.
Lifecycles can be derived from other lifecycles. A derived lifecycle starts with all of the same phases as the original lifecycle. If the original lifecycle changes, then the derived lifecycles are marked as noncompliant. You must update the derived lifecycles to match the original lifecycle.
When you create a release, you select a lifecycle for that release. Then, you assign release environments to the lifecycle phases. In this way, the lifecycle is a template for the work in a release.
The following figure shows the default lifecycle, which has five phases, including a development phase, testing and certification phases, and a production phase. By default, this lifecycle has no gates; you can add gates manually.