To quickly become productive with IBM® UrbanCode Release, review the following topics in order.
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.
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 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.
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.
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 applications with a release.
For information about integrating IBM UrbanCode Release with external tools, see Configuring integration providers.
The phases available to a release are defined in the lifecycle that is selected for it. It might be helpful to think of a lifecycle model as a template used to create and drive releases. A lifecycle defines the progression of phases through which software passes on its way to production, which is represented by a production phase, or some similarly designated final phase. The lifecycle does not specify which particular environments are used for a release, but the general pattern. For example, a lifecycle might have the following phases: Development, Quality Assurance, and Production. Releases based on this lifecycle have all three phases, although the actual environments used might vary from release to release. A lifecycle can also define the quality steps, called gates, required to be successfully completed before software is permitted to progress to the next phase.
Develop strategies appropriate for each phase; strategies for high-ceremony production deployments might be inappropriate for low-ceremony environments.
The first step to define the path to production is to determine whether an existing lifecycle model can be used, or if an entirely new one is required. Starting fresh with IBM UrbanCode Release naturally requires the creation of lifecycles that mirror your normal processes and environments. As your experience grows, you will develop a stable of lifecycles that can handle most, if not all, of your releases. So the activities required to define the path to production are largelydetermined by the availability of suitable lifecycles. The following tables outline whether or not a reusable lifecycle is available for a variety of activities.
Activity | Description |
---|---|
1. Name the lifecycle's phases. | Environments are mapped to phases. |
2. Define Statuses. | Statuses are user-defined values, such as "Passed" or "Archived." |
3. Add gates. | A gate is a mechanism that ensures items cannot be deployed into a phase/environment unless they have a gate-specified status. Gates establish minimum entrance requirements to a phase. |
Activity | Description |
---|---|
1. Allocate environments to phases. | Identify the environments to be used during each lifecycle phase. A release environment is a user-defined construct that represents deployment targets; a release environment aggregates deployment environments. |
2. Define approvals. | An approval is a mechanism that is used to control environments, regardless of quality (status) considerations. Approvers are designated by role; any user with the specified role can provide approval. |
3. Select deployment plan. | A deployment plan defines how much orchestration and coordination is required for a successful deployment for a particular phase. |
Known production and pre-production dates can be recorded and disseminated by scheduling deployments to the release environments.
Dates are defined when a new deployment is scheduled (
).A recurring window, or recurring deployment, are created for deployments that recur at predictable intervals. Recurring windows can be triggered hourly, daily, weekly, or by some cron expression.
Milestones are activities, typically process checklist items, that must be completed in order for the release to remain on track. A milestone can represent anything that requires tracking, such as a kick-off meeting, operating system upgrade, or hardware and network upgrades. Milestones are tracked by date and status.
Milestones are attached to the release itself and not a particular phase or environment. Milestones are created on the Release page ( ).
Although it might be tempting to concentrate on functionality that is identified during planning, remain alert to potential changes that rescope or otherwise effect the release train's schedule.
Release teams, as you might guess, manage releases. A team consists of roles and users that are configured in the IBM UrbanCode Release security system. A release must have at least one role that is configured for it. Typical roles are Admin, Release Manager, and User; all of which are available by default. Roles can be reused.
Roles are defined on the Roles page ( ).
An approval is a mechanism that is used to control environments, regardless of quality (status) considerations. A release that requires approval cannot proceed with a phase until approval is granted. Approvals are attached to phases. Approvers are designated by role; any user with the specified role can approve.