In general, you use 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 execute production deployment.
The following sections summarize the activities performed to implement a release.
Setup Activities
Table 1. Setup Activities
Activity | Description |
---|---|
1. Installation. |
Install UrbanCode Release as a Tomcat web application. See Installing and Integrating. |
2. Configure integrations. |
Make external objects available by configuring integrations. IBM uDeploy applications and components, for example, become available once IBM uDeploy is integrated with UrbanCode Release. |
3. Define release environments. |
Create the environments that will be mapped to release phases. When a release is created, you assign an environment to each phase. |
Planning the Release
Start by determining the scope of the anchor functionality and assign a date that accommodates it, then work backwards from there. View each release as a date-driven project.
Table 2. Planning Activities
Activity | Description |
---|---|
1. Create or name the release. |
Give the release a meaningful name and description; determine if it will be a major or minor release. |
2. Applications. | Associate applications with the release. |
3. Define path to production. |
A release life cycle specifies the progression of environments through which software passes on its way to production. The life cycle 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 is required for a successful deployment at given phase of the life cycle. |
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 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. See the section called “Define Milestones”. |
7. Configure the release team. |
Select a team to manage the release. |
8. Add approvals. |
An approval is a mechanism used to limit deployments to an environment regardless of quality (status) considerations, in order to ensure any work being done there is not interrupted. |
Integrate and Test
A deployment can contain all applications in a release, a subset, or represent a one-off emergency deployment.
Table 3. Deployment Activities
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. Once 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 have met 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 used to limit deployments to an environment regardless of quality (status) considerations. |
7. Execute deployments. |
Deployments are performed by running tasks defined in the deployment plan. |
8. Complete milestones. |
Update milestone status upon completion. Milestones extra-deployment items that can represent anything related to the release. |
Execute Production Deployments
Table 4. Production Activities
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 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, enabling you to obtain real-time statuses for an ongoing release from a single place. |