The Deployment Path application is included in the Release Package process app.
Deployment paths are a sequence of environments through which a deployable release train or release package must progress. Deployable release trains and parent-child release packages hierarchies are typically configured to progress through deployment paths that include only production-level or final environments, whereas standalone release packages typically progress through testing paths, such as development testing, integration testing, system integration testing, and user acceptance testing. For some typical scenarios, see the following:
- A Typical Release Control Flow Using Deployable Release Trains
- A Typical Release Control Flow Using Planning Release Trains
- A Typical Flow Using Release Packages Only
Deploying through a pre-defined path ensures that your release has gone through the required testing stages before it moves to production. You can define whether each environment is required or optional on this path. You can also define environments as locked to prevent further changes, ensuring that what was previously tested is deployed to your production environment.
Deployment paths can be associated with specific release types, which enable you to limit the selection of paths available for a deployable release train or release package. For example, you may have "major", "minor", and "emergency" release types. Only the deployment paths with a release type that matches the release type specified for the train or package can be selected.
The deployment path is designed using the graphical interface to add, modify, and delete the environments in the paths. For example, a simplified environment sequence would be the following:
- DEV (Development)
- INT (Integration Testing)
- UAT (User Acceptance Testing )
- PROD (Production)
An example deployment path is shown in the following figure.
- Each environment is represented by a box. An R in the bottom left of the box means the environment is required.
- A successful deployment moves a release package to the next environment in the state.
- If an environment allows redeploy, a returning line appears at the top of the diagram.
- Failure selections are shown on the bottom of the diagram.
- A lock icon indicates which environments are locked.
Deployment paths follow a process organized into these stages:
- Release Engineers
Typically, deployment paths are created when you implement Release Control for your organization. You generally have a limited set of deployment paths that should be available to use for your release packages, and those should be defined and ready to be selected by release engineers who use Release Control to deploy release packages.
Create
While a deployment path is in the Create stage, release engineers can:
- set release type
Note: Multiple deployment paths may have the same release type. For example, you may have a Major release type that includes a full set of environments for one team, and another that includes a full set of environments for another. Although they are both Major release types, they may follow slightly different deployment paths.
-
select and add eligible environments to the path in a sequence
-
set options for the environment on the path, such as:
-
Required: Indicates whether deployment to an environment is required or optional
-
On Fail: Specifies which environment to go to in case of a failure
-
Set Lock: Indicates whether an environment is locked, so that no changes are allowed to the release package when it is deployed to that environment unless it is reverted to a different environment; this can be used to implement a code freeze.
-
Redeploy: Indicates that the deployable release train or release package may be deployed again into the same environment
-