Planning releases

You schedule a deployment by selecting the release, deployment plan, and start date among other things. You run a deployment by resolving its tasks. You resolve tasks by applying statuses to them, such as Complete, or Skipped. When all tasks are resolved, the deployment is complete.

Planning the release means answering some basic questions about its scope. Is it an entirely new release? Or does it use a previously defined plan? Perhaps it is a minor release, such as a patch, that requires almost no changes to an existing release? The answers to these questions determine your path to production, and whether you can reuse an existing release, and if so, to what degree.

Note:

Ensure the inputs to the release train come from synchronized and open team-based planning. The goal is to define a set of clearly articulated deliverables and interdependencies.

The path to production refers to a succession of phases that culminate in the final phase, production. At its simplest, a phase represents one or more environments and quality requirements. A phase can have more items as well, such as quality statuses and gates.

The progression of phases is defined by a lifecycle model. When you create a release, the phases available to it are defined in the lifecycle model that is selected for the release. If a phase you need is not defined in a lifecycle, you can modify the model or create an entirely new one. IBM® UrbanCode Release provides a default lifecycle that you can modify as you see fit.

The following figure illustrates two releases, October and November, that use the same lifecycle model. The phases that are defined in the model are listed across the top. Environments are allocated to releases and each phase is assigned one, which is shown in the illustration. The October Release, for example, uses the DEV-1 environment during the DEV phase, while the November Release uses DEV-2 for that phase. The gates between phases are defined in the model.

A diagram that shows the phases and gates for two releases

A lifecycle can be used for any number of releases. By varying the environments and applications (note that the lineup of applications differs between releases) you can craft releases for nearly any eventuality from the same lifecycle. If a lifecycle is unsuitable for a particular release, for example with either too many phases or not enough, you can create a new lifecycle model at any time.

You can use IBM UrbanCode Release to lay the track between pre-production and production and reliably run releases down the track. The release train can be provisioned by any type of rolling stock (automated, manual, and ad hoc processes), and carry any type of freight. The release train's predictable schedule drives the release process. By using IBM UrbanCode Release you can integrate and synchronize team-based planning to arrive at a clear, open, and transparent plan. All stakeholders know the schedule and key milestones, and can be assured that the releases depart on schedule and arrive on time.

Create the Release

Narrowly speaking, creating a release means using the web user interface to give it a name, and select a lifecycle and team. More generally, it means determining whether it is a major or minor release. As a rule-of-thumb, a minor release is one that can use an existing environments and applications or subset of its applications; a major release requires new environments and applications.

Associate Applications With the Release

Although applications are not required (you might create a release that is composed entirely of milestones and infrastructure-related tasks, for example), most of releases by far involve deploying applications. Applications can come from integration with external tools such as IBM UrbanCode Deploy, or be created within IBM UrbanCode Release itself. Each release has all the applications that are defined in IBM UrbanCode Release available to it. You can associate any number of applications with a release.

For information about integrating IBM UrbanCode Release with external tools, see Configuring integration providers.


Feedback