In general, you use IBM® UrbanCode Release at several key points during a release cycle:
Setup.
Plan a release.
Build, integrate, and test the system to be released.
Plan, practice, and run production deployment.
The following sections provide a high-level summary these activities.
Activity | Description |
---|---|
1. Installation. | Install IBM UrbanCode Release as a Tomcat web application. See Installing the server. |
2. Configure integrations. | Make external objects available by configuring integrations. IBM UrbanCode Deploy applications and components, for example, become available afterIBM UrbanCode Deploy is integrated with IBM UrbanCode Release. |
3. 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 is useful:
Activity | Description |
---|---|
1. Create or name the release. | Give the release a meaningful name and description; determine whether it is a major or minor release. |
2. Applications. | Associate applications with the release. |
3. Define path to production. | A release lifecycle specifies the progression of environments through which software passes on its way to production. The lifecycle does not indicate which specific environments are used for a release, but the general pattern, such as, DEV, INT, QA, UAT, PROD. It can also define the quality steps the software must successfully complete before being permitted to progress to the next environment. Finally, selecting a deployment plan determines how much orchestration and coordination are required for a successful deployment at given phase of the lifecycle. |
4. Identify the production date and known pre-production dates. | Known production and pre-production dates can be recorded and disseminated by scheduling deployments to the environments allocated to the release. |
5. Define recurring windows. | Recurring windows can be used for deployments that are occurring on some regular interval, such as daily or weekly. |
6. Define milestones. | Milestones are release-level checklist items that are tracked by date and status. |
7. Configure the release team. | Select a team to manage the release. |
8. Add approvals. | An approval is a mechanism that is used to limit deployments to an environment regardless of quality (status) considerations to ensure any work that is being done there is not interrupted. |
A deployment can contain all applications in a release, a subset, or represent a one-off emergency deployment.
Activity | Description |
---|---|
1. Schedule ad hoc deployments, if needed. | Ad hoc deployments can be scheduled at anytime, so an exhaustive list of scheduled deployments is not necessary at the outset. Recurring windows can be defined and tested. |
2. Update scheduled deployments. | Add specific application versions to deploy. |
3. Review the deployment plan's tasks. | Change tasks as required. Tasks can be added manually to a scheduled deployment, or can be imported through CSV files. After a task is defined and saved, it becomes part of the deployment plan and is available for future deployments. |
4. Certify application versions by applying quality statuses. | Quality statuses indicate that versions meet quality requirements. Statuses can be assigned manually, or through integration with external tools. |
5. Grant gate exemptions. | Approvals and gates can be suspended whenever an emergency deployment is required. |
6. Approve deployments. | An approval is a mechanism that is used to limit deployments to an environment regardless of quality (status) considerations. |
7. Run deployments. | Deployments are performed by running tasks that are defined in the deployment plan. |
8. Complete milestones. | Update milestone status upon completion. Milestones extra-deployment items that can represent anything that is related to the release. |
Activity | Description |
---|---|
1. Verify deployment plan prerequisites. | A deployment plan consists of segments, which are groups of tasks that are to be completed at the same time. A segment cannot be started until all its prerequisites are completed. All segments can have prerequisites except the first one. |
2. Verify overall schedule. | Ensure that all tasks have the expected duration; segment length is calculated by using task durations. |
3. Assign or claim tasks. | Tasks can be assigned to a role or to a specific user. Unassigned tasks can be claimed by anyone with the defined role. |
4. Configure notifications | Notifications can be attached to plan, segment, or task, and set to trigger in several ways. Email notifications can be sent to users whenever user-defined trigger events occur. |
5. Monitor deployments. | The dashboard provides a centralized portal into your releases. You can obtain real-time statuses for an ongoing release from the dashboard. |