Managing releases

Creating releases

A release is the core feature of IBM UrbanCode Release. A release defines the activities, team, and quality controls that are required for a successful software release. Narrowly speaking, creating a release means naming the release and selecting a lifecycle and team. After you create the release, you associate release environments with the lifecycle's phases, and add applications to the release. In addition, you can add checklists and initiatives to the release. By using the tools in IBM UrbanCode Release, you can fashion releases that reflect your current framework.

When you plan a release, you establish its scope; you can easily create both major and minor releases. A major release typically requires new environments and applications, and a minor release typically reuses existing environments and applications or subset of its applications. A release can participate in an enterprise-wide event that coordinates several releases simultaneously. You also determine which other processes, such as lifecycle or process checklists, to use or create. Finally, you establish both the release processes and deliverables and the relationships and dependencies with other releases.

Configuring releases

Each release is based on a lifecycle. The lifecycle specifies the number of phases for the release and their progression. A lifecycle can include any number of phases, such as development and quality assurance, and usually ends with a production phase. If a phase that you require is not defined in a lifecycle, you can modify it or create a new one. IBM UrbanCode Release provides a default lifecycle that you can modify to reflect your release process.

You specify one or more release environments for each phase. A release environment represents the target for a deployment. You can deploy applications by associating application environments with release environments. Each phase can have one or more phase approvals, which require the approval of a certain role before the application can move to the next phase. Releases can also have quality gates, or statuses, that must be applied to applications before they can be deployed.

You can also add a process checklist to the release. Process checklists consist of milestones. You use milestones to track release events that are outside typical deployment tasks. For example, you can create milestones to represent cross-team project meetings or tasks that must be completed by certain dates.

Managing applications

Although you can create a release that is composed entirely of milestones and infrastructure-related tasks, most releases involve deploying applications. The term application is used in two ways. First, it refers to the applications that you import from IBM™ UrbanCode Deploy and run with automated deploy tasks. Second, the term application refers to objects you can create with IBM UrbanCode Release and manage with manual tasks. Manual applications do not have automated processes and are used to manage activities related to applications, such as preparing their environments. Each release has available to it all the applications that are defined in IBM UrbanCode Release. A release can contain one or more applications, and an application can be part of any number of releases.

Running releases

A release is completed by performing deployments. A deployment is a set of tasks that, when completed, implement a release for a specific release environment. Typically, you run one deployment for each phase in your lifecycle. If your lifecycle has five phases, a complete release would consist of five deployments, one for each phase. In addition to complete releases, you can run ad hoc or minor releases that might contain fewer deployments than called for by the lifecycle. By varying the environments and applications, you can craft releases for nearly any eventuality.

Enterprise releases

You can combine multiple releases into a single event. You can combine releases into one enterprise-wide release plan, or you can orchestrate multiple release plans. You can create dependencies between release plans that ensure that all plans align and move at the same cadence. By creating signal tasks, dependencies across plans can be reliably resolved and coordinated.