Integrate and test
After a release plan is finalized, it's time to test it and deploy it to non-production environments.
Releases are implemented by deployments. A deployment targets a single phase and its associated environment (each phase has a single environment that is associated with it). A deployment can be broad-based and use all applications in a release, represent a one-off emergency deployment of, say, a single application, or anything in between. Deployments can be as precisely targeted as necessary.
IBM® UrbanCode™ Release deployments bring together:
The schedule that defines when the deployment occurs and specifies whether it is a one-time or a recurring event
Email notifications that are triggered by user-defined events and sent to a particular user or a user role
Deployment, or deployment plans, are composed of segments. A segment represents release activities that are intended to be completed together. A segment can be configured to run after the successful completion of another segment, or can run independently of any other segment. A deployment plan can have any number of segments. The default plan has two segments: Pre-Deployment Tasks, and Deployment Tasks.
After a deployment plan is defined, a deployment can be initiated at any time with a deployment request. A deployment request can start an entire deployment or a portion of the plan, such as an individual segment.
Ensure that every team has a fall-back plan in addition to its primary one. The fallback plan can be a simple as rolling-back to an old version until blocks are resolved.
Schedule Ad Hoc Deployments (Optional)
An ad hoc deployment is, as the name implies, an unplanned deployment. Ad hoc deployments can be scheduled at anytime, which means you do not have to define an exhaustive list of deployments during release planning.
Testing in typical environment progressions is important, including recurring windows, but be flexible enough to repurpose environments if expected environments become unavailable.
Update Scheduled Deployments
Typically, the lineup of applications is defined when the release is created. Applications that are associated with the release are automatically available to any deployment that uses the release. Applications and applications suites can be promoted to released versions. Typically, a released version represents an application (or suite) that was successfully deployed and can reliably be reused.
Additionally, you can add applications to a release after deployments are scheduled for it. New applications become part of any upcoming or in-progress deployment.
Define Deployment Tasks
Deployment activities are defined by tasks. An individual task is a unit of work that can represent any business-meaningful activity that is associated with a release. Tasks can be configured to run once, or every time the deployment plan is used. A task can be assigned to a user role or specific user; and if unassigned, can be claimed by anyone with the requisite role. After a task is defined, it is added to the task library and becomes available for other deployments.
When a task is created, it is given a duration, which is an estimate of the time it takes to complete. IBM UrbanCode Release aggregates task durations to calculate overall deployment times.
Tasks can be automated or manual. Automated tasks come from integrations with external tools. Application processes from IBM™ UrbanCode Deploy applications, for example, are available as automated tasks in IBM UrbanCode Release.
Manual tasks can represent any non-automated task, such as stopping or starting a server. Unlike milestones that are defined for the overall release, manual tasks (and automated tasks) are attached to a particular phase and segment. A segment can be considered a grouping of tasks that are intended to finish at the same time.
Typically, tasks are defined on the Scheduled Deployments page in the web application, but they can also be exported and imported (as CSV files).
Certify Application Versions
Application versions can have quality statuses. Quality statuses ensure that application versions meet some expected quality requirement. Statuses can be assigned manually, or through integration with external tools.
Grant Gate Exemptions
Approvals and gates can be temporarily suspended whenever an emergency deployment is required.
An approval is a mechanism that is used to control environments, regardless of quality (status) considerations. Approvals are attached to phases. A release that requires approval cannot proceed with a phase until approval is granted. Approvers are typically designated by user role. Any user with the designated role can respond to an approval request. If, for example, the QA phase requires approval by the release manager, the release is not able to proceed until approval is granted by someone with the release manager role. Specific users can also be designated to approve.
If a scheduled deployment that requires approval reaches its start time without receiving approval, the phase does not proceed and is considered rejected by the approver.