Phases in a release are derived from the lifecycle; segments and tasks in a phase are derived from the deployment plan. When you create a deployment, you select a deployment plan from the plans that are associated with the release. The plan that you choose determines the segments and tasks that are initially available for the deployment. You can add or delete segments and tasks even after the deployment starts. Changes that you make to a plan during a deployment become part of the plan itself. You can also work on a deployment plan directly outside of any deployment.
Typically, you create deployment plans from existing plans but you can start with a blank plan. When you create a deployment plan, regardless of whether it is based on an existing plan, you associate it with a release. Each release-plan combination is unique. When you create a deployment for a release, the deployment plans that are associated with the release are available. Deployment plans that are associated with other releases are not available.
Changes that you make to a plan during a deployment become part of the plan. The changes are available the next time a deployment uses the same release-plan combination. For example, if you run a deployment with the Plan1-ReleaseA combination, changes that you made to the Plan1 are available the next time you create a deployment with this release-plan combination. Changes that you make to a plan do not affect other deployments that are in progress when the changes occur.
You can attach a plan from one release to another release. When you attach a plan, you rename the plan and it becomes a separate, unique plan-release combination. For example, if you attach Plan1 to a different release, the new plan has all changes that are made to Plan1 up to the time that it is attached. Subsequent changes that are made to Plan1 do not affect the new plan, nor do changes that are made to the new plan affect Plan1.
IBM® UrbanCode Release provides a default plan for you to modify and copy. The simple default plan is automatically attached to every release.
Segments contain the tasks that define a deployment. Typically, a segment groups tasks that are related in some business-meaningful way. All tasks in a segment must be resolved before the segment is considered complete. A deployment plan can have any number of segments. A segment can have any number of tasks. The number of segments and their composition is up to you.
A segment's tasks cannot be started until the segment itself is started. A segment can be assigned an executor role, in which case only users with that role can start the segment. After a deployment starts, a segment can be started at any time unless it has prerequisite segments. If a segment has prerequisite segments, it cannot be started until all prerequisite segments are complete.
Time estimates that are used to determine a deployment's overall progress are calculated for each segment. Any number of segments can be in progress simultaneously.
A task represents some business-meaningful activity that has starting and ending points and a measurable duration. Duration is estimated when a task is created and the value is used to compute the segment's progress. As with segments, a task can be assigned an executor role.
A task can be manual or automatic. A manual task can represent any activity that is related to a release, such as taking a server offline. An automatic task is an application process that is imported from IBM UrbanCode Deploy. When an automatic task starts, feedback is generated as the task interacts with IBM UrbanCode Deploy. For information about integrating with IBM UrbanCode Deploy, see Integrating.
When you create a segment, you choose whether the tasks it contains are done sequentially or simultaneously. Your choice determines how the segment's duration is calculated. Parallel tasks are assumed to start when the segment starts and the duration is equal to the length of the longest task. Sequential tasks are also assumed to start when the segment starts but duration is calculated by adding the times for all tasks. Finally, you can specify the Sequential Execution Enforced option, which means that only the first task starts when the segment starts and all tasks must be done in order.
A task can have dependency relationships with other tasks. A task can depend on another task, or act as a prerequisite for another task. When a task depends on another task, it cannot be started until the prerequisite task completes. A task can have multiple dependent tasks, and multiple prerequisite tasks. If a task has multiple prerequisite tasks, it cannot start until all prerequisite tasks are completed.
A task can have a dependency relationship with other tasks within its deployment plan. You can define dependencies when you create a deployment plan, or when you run a deployment.