The following diagram outlines the basic steps that are required to create a release and run a deployment in a release environment. Each box describes a core activity and, taken together, illustrates the product's primary function. The fastest way to become productive is to work through these steps and understand what each does and how each interrelates with the others.
Activity | Description |
---|---|
Configure integrations | Make external objects available by configuring integrations. IBM UrbanCode Deploy applications and snapshots, for example, become available afterIBM UrbanCode Deploy is integrated with IBM UrbanCode Release. |
Create applications | Create applications that are used in manual tasks. See Creating and configuring applications. |
Define release environments | Create the environments that are mapped to release phases. When a release is created, you assign an environment to each phase. |
Each release presents its own challenges, but the following approach can be useful:
Activity | Description |
---|---|
Create the release. | Give the release a meaningful name and description. |
Associate applications with the release | Although applications are not required (you might create a release that is composed entirely of milestones and infrastructure-related tasks, for example), most releases involve deploying applications. Applications can come from integration with external tools such as IBM UrbanCode Deploy, or be created within IBM UrbanCode Release itself. |
Define path to production | The phases available to a release are defined in the lifecycle that is selected for it. It might be helpful to think of a lifecycle model as a template used to create and drive releases. A lifecycle defines the progression of phases through which software passes on its way to production, which is represented by a production phase, or some similarly designated final phase. The lifecycle does not specify which particular environments are used for a release, but the general pattern. For example, a lifecycle might have the following phases: Development, Quality Assurance, and Production. Releases based on this lifecycle have all three phases, although the actual environments used might vary from release to release. A lifecycle can also define the quality steps, called gates, required to be successfully completed before software can progress to the next phase. |
Map release environments to phases | Identify the environments to be used during each lifecycle phase. A release environment is a user-defined construct that represents deployment targets. |
Identify deployment dates and reserve release environments | Known production and pre-production dates can be recorded and disseminated by scheduling deployments to the environments allocated to the release. To avoid conflicts with other releases, reserve release environments. |
Deployment plans define the segments and segment-related tasks that drive deployments.
Activity | Description |
---|---|
Create a deployment plan. | Typically, you create deployment plans from existing plans but you can start with a blank plan. |
Create plan segments | Segments are containers for tasks that have some user-defined relationship and that must be finished together. |
Create automatic tasks | A task represents a release activity that has starting and ending points and a measurable duration. Typically, automatic tasks represent application processes that are imported from IBM UrbanCode Deploy. |
Create manual tasks | When you create a manual task, you specify its duration and define its pattern. The pattern determines how frequently the task can be used and the release environments where it can be used. |
Associate the plan with a release | When you create a deployment plan, you associate it with a release. Each release-plan combination is unique. |
You complete a deployment by resolving its tasks. Resolve tasks by starting them and then applying various statuses to them.
Activity | Description |
---|---|
Schedule the deployment | When you schedule a deployment, you select the release, the release environment, associated application versions, and the deployment plan. Beginning at the scheduled start time, your team resolves the deployment's tasks. Deployments can start automatically or manually. Rules can also be defined to run deployments on a recurring schedule. |
Select application versions | If you did not configure the deployment to automatically select application versions, you can select versions anytime before the deployment starts. Automatic tasks without designated application versions cannot run. |
Configure notifications | Notifications can be set to trigger in several ways. Email notifications can be sent to users whenever user-defined trigger events occur. |
Start the deployment. | When a deployment starts, regularly updated feedback provides information about the deployment's progress. You can also modify existing tasks and add new ones even after the deployment starts. |
Start segments. | The tasks in a segment cannot be started until the segment itself is started. More than one segment can be started and be in progress at the same time. If a segment has prerequisites, it cannot be started until all prerequisite segments are complete. |
Claim and resolve tasks | Before a task can be started, it must be claimed by a user with the role that is assigned to the task. A task is resolved by changing its status. |
When all tasks are resolved, the deployment is complete.