Releases allow you to orchestrate multiple applications or microservices across multiple environments and to manage the software release life cycle using one platform. It brings together everything you need to take your software through its journey to production, regardless of your software release processes. You can manage traditional release processes (culminating in one big software release at the end of the software delivery life cycle), CI scenarios (build-test automation), CD scenarios (deployment automation), or a combination of these methods using a single platform. You can also manage and control dependencies with this platform.
Modeling releases
You can model a Release by defining the Release process that consists of the following:
-
The bill of materials consisting of the multiple applications or microservices that you want to deploy.
-
One or more environments where the applications or microservices will be deployed or installed during the Release run.
-
Pipelines and any inputs to the applications or microservices (parameters created for them) specifying how the applications or microservices will be deployed. Pipelines are the paths to production, and all the other objects in the Release are linked to the selected pipeline.
-
The pipeline approval gates that determine when tasks in the stage can start or when the pipeline can enter or exit a stage.
-
Approvers and task assignees perform specific activities as the Release runs. Individual users and teams are notified when an action needs to be taken.
The Release feature leverages the pipeline capability and a special type of pipeline task called a deployer to deliver an auto-flexing mechanism where the same pipeline can be used across multiple releases. For example, you have a standardized process for your major releases, and the only things that normally change are the applications or microservices and their released versions. In this case, you do not want to specify the exact applications or microservices to deploy as part of the pipeline tasks, which do not allow for pipeline reusability. This is where a deployer task in the pipeline and Release capability work together to provide reusability.
The deployer task, previously mentioned in Pipelines, is a special type of task specified in the task list of a pipeline stage. It gets the actual list of applications or microservices (and the number of applications or microservices) to deploy from the bill of materials in the Release definition. This list is considered the payload of the Release. At runtime, the list of applications or microservices to deploy is passed to the pipeline through the Release object. The pipeline then deploys the applications or microservices in sequential order. So you can create one pipeline that works for different software releases.
You can have multiple deployer tasks in a pipeline stage. Using multiple deployer tasks in a pipeline stage lets you deploy applications or microservices in parallel rather than in series.
In a pipeline stage, you can define a task using out-of-the-box third-party integrations (plugins) such as:
-
Artifact repositories such as Git, Perforce, Subversion, Microsoft Team Foundation Server (MS TFS), Accrue, ClearCase, Repo, and Vault
-
Issue tracking products that provide application or microservice developers with requirements tracking such as HP Application Lifecycle Management (HP ALM), Bugzilla, ClearQuest, Fortress, JIRA, HP Quality Center (HPQC), Rally, IBM Rational Team Concert, TeamForge, and TestTrack
-
IT service management (ITSM) products such as ServiceNow
-
Project management products such as Rally
For a complete list of supported plugins, go to the CloudBees Plugins directory.
For details about tasks in pipeline stages, refer to Editing a Pipeline Definition.
CloudBees CD/RO provides multiple project support for objects in application deployments, pipelines, and releases. These objects as well as the objects belonging to them can be in any project within CloudBees CD/RO.
All objects in CloudBees CD/RO have these capabilities for better management and maintenance of end-to-end software releases:
-
Projects are top-level security containers that provide access control at the project level. All objects in a project inherit the access control settings from the project to which they belong.
-
Projects are also ways to provide logical groupings of objects. If your deployment is large and has many production environments, you can organize production environments by project, with each project having its own access control settings. This makes it easier to manage and maintain multiple environments during the software delivery process.
Setting up releases
This section describes how to set up releases. To get started defining the Release process, select a pipeline on which the process is based. This pipeline needs to have one or more deployer tasks in its stages. Then, you select the applications or microservices that you want to deploy (the bill of materials), the environment where the applications or microservices will be deployed, and any inputs to the applications or microservices. For instructions, refer to Release Definition.
To get a bird’s eye view of all the releases that are planned, active, or completed, refer to Release Dashboard. To view the bill of materials, refer to Path-to-Production View. To view the pipeline’s progress during the Release run, refer to Pipeline Stage Summary. For instructions on how to set up objects in a release:
-
Refer to Examples: Modeling and Deploying Applications to set up applications or microservices.
-
Refer to Master Component Examples for examples of how to create and add parameters to your applications or microservices. The steps apply to applications or microservices with master and normal components.
-
Refer to Pipelines to set up pipelines.
CloudBees CD/RO supports resource exclusivity at the platform level. This allows a procedure to lock a resource for a job step and execute the tasks. The job step acquires and retains exclusive use of a resource, ensuring that the resource is always available for the step.
| When an application, a pipeline, or a release is cloned across different projects, you might need to fix the references after the objects are cloned. For example, if a pipeline with an application reference in the "default" project is cloned to a different project, the application reference needs to be fixed after the pipeline is cloned. |
When you export a project while a pipeline is in progress, only the full export includes flow runtimes that have been completed. If you want to include in-progress pipeline runs in the path-to-production view and the visual indicators showing their percentage completed in the Release Dashboard, set the excludeJobs argument to 0 or false in the export command. When the XML file is imported, the in-progress pipeline runs in the imported project are displayed in the path-to-production view and the Release Dashboard. The jobs might be incomplete once the XML is imported.
|
Controlling the releases
CloudBees CD/RO provides these ways to ensure that the Release runs are successful:
-
Manual gates:
For each stage in the Release pipeline, an entry gate controls when the tasks can start. If the conditions and approvals are met, the process flow can proceed and the tasks can be executed. The process flow can complete the stage and proceed to the next stage when the exit conditions and approvals are met.
CloudBees CD/RO sends notifications to the appropriate approvers, users, and/or groups.
Refer to Visibility and Status of Release Pipelines for an example process flow.
-
Preconditions:
You can set Run if and Wait until conditions on stages, tasks, and gates in pipelines. For more information, refer to Pipeline Concepts.
You can set conditions in process branching when authoring application, microservice, and component processes. These conditions determine the path that the Release takes through the process flow. Refer to Process Branching for instructions to set conditions on the transitions between process steps.
You can set preconditions on procedure steps.
-
Completion status: Completion status of each stage is recorded with a completed flag. This flag is set automatically or manually, based on the Completion Status Update setting in the stage details.
-
Automatic completion: The completed flag is automatically set the stage’s post gate completes, or if no post gate, when the last task in the stage completes. If a stage is rerun after it has been marked completed, it is automatically unset (stage now marked as incomplete).
-
Manual completion: After the stage’s post gate completes, or if no post gate, when the last task in the stage completes, the completion status must me manually set. In order to rerun after it has been marked completed, it must be manually unset (stage now marked as incomplete).
You can view a stage’s completion status from the Release editor. Stages pending manual completion update are noted with a checkbox.
-
-
ServiceNow integration: Use the ServiceNow plugin to integrate IT service management (ITSM) with CloudBees CD/RO.
-
Plugins: You can use third-party plugins to execute the conditions and rules for approvals and quality gates.
-
Postp: You can use postp to get data from the log files, make it appear on the Job Details page, and use it to take action on the Release run. For more information, refer to Postp.
Release planning and tracking
CloudBees CD/RO can capture planning data beyond just the planned start date and time and end date and time of a release. For better planning and tracking, teams involved in a release can capture planning data at a granular level. Release managers can analyze release pipelines, get statuses of different stages and tasks, identify bottlenecks, and reduce failures.
Hierarchical releases and pipelines with portfolio views
Enterprise releases can be complex with many moving parts, nested hierarchies, and dependencies. Enterprise releases are often composed of other “subreleases” and groups of applications, each with its own pipeline and timelines.
With support for hierarchical releases and pipelines in CloudBees CD/RO, you can model, automate, and visualize dependencies across releases. You can use CloudBees CD/RO to set up releases or pipelines that trigger subreleases, with the ability to model multilevel hierarchies of nested releases. Triggers and dependencies can be configured anywhere, with configuration options to provide needed flexibility.
In addition to dependency modeling, the Pipeline Portfolio View and the Release Portfolio View in CloudBees CD/RO provide top-down visibility into the entire dependency hierarchy. At runtime, this view gives detailed insight into the status of each pipeline in the hierarchy, down to the stage level to show successes, failures, and waits for manual tasks or dependencies. This view provides the status of all related releases at a glance, including drill-downs into dependencies, so you can easily understand progress and identify delays, which significantly simplifies enterprise release management.
The Pipeline Portfolio view and the Release Portfolio view show duration information for each pipeline in the hierarchy and its stages visible at the top level.
Pipeline views
Pipeline portfolio view
To view the Portfolio View for a pipeline, select Pipeline portfolio at the top of the pipeline editor. The following screenshots provide an example of hierarchical pipelines with a master pipeline named OnlineBanking and its Pipeline Portfolio view at runtime.
The pipeline portfolio view shows that the eTransver pipeline is waiting on other events in other pipelines. Select its Waiting on icon to discover it is waiting on the BillPay and ICT sub-pipelines.
Pipeline portfolio list view
Alternatively, view the pipeline run via the Pipeline Portfolio List view. This view is useful with large pipelines enabling them to be viewed at scale, displaying the hierarchy in a linear fashion. From here you can filter the hierarchy to hone in to parts of the pipeline of interest. You can view pipelines waiting on an action and pipelines pending manual input.
Release views
Release portfolio view
The Release Portfolio View provides a top-level view of the entire hierarchy of releases. As you are authoring, this view provides a clear understanding of the connections and dependencies between releases down to specific stages in each release pipeline.
To view the Portfolio View for a release, select Release portfolio at the top of the screen.
At runtime, as releases are in progress, this top-down view gives detailed insight into the status of the release hierarchy with live status on each pipeline down to the stage level. This shows whether the stage is actively running, completed successfully, or has failed. This visibility down to stage-level status provides detailed information for each release from the Portfolio View, so you do not need to open each release to check for progress through the stages.
You can drill down into dependency details to identify delays. Stages waiting for dependencies are highlighted with the Waiting on icon; select it to access a list of dependencies that the release is waiting for. This visibility lets you identify inefficiencies or process bottlenecks and take appropriate action:
Release portfolio list view
Alternatively, view the release run via the Release Portfolio List view. This view is useful with large releases enabling them to be viewed at scale, displaying the hierarchy in a linear fashion. From here you can filter the hierarchy to hone in to parts of the release of interest. You can view release pipelines waiting on an action and those pending manual input.
Dependencies and dependency skipping wait
You can set dependencies on any stage or task in a pipeline or release to wait for subreleases to complete. Invoking a parent pipeline or release will continue only when the wait dependency is satisfied (such as when a stage, a task, or the subpipeline itself completes). These wait dependencies can be set to wait for entire subpipelines or releases to complete or to wait for specific stages or gates. At runtime, all dependencies are automatically enforced to reduce the need for manual intervention or checks.
When defining pipeline or release wait dependencies, you can configure whether skipping is allowed and the users who are allowed to skip. This lets you make your hierarchy more secure during runtime.
Following is an example of how to configure wait skipping on the eTransfers pipeline.
The following figure shows an example of a release that is configured to allow skipping. At runtime, select the indicated skip wait button to request a skip. You are asked for confirmation after you select a skip wait button.
The wait skip button is visible only to the users who are allowed to skip the wait dependencies.
Usage scenarios for hierarchical releases and pipelines
The following scenarios illustrate several benefits of using this feature:
-
Several release pipelines depend on each other at different stages. These release pipelines deploy into shared environments, and some stages might provision environments used by the release or other releases. If a stage misses its deadline, it can cause a cascading effect to delay other releases. Hierarchical releases provide a high-level view into all pipelines to assess risk in the release and bottlenecks or delays.
A specific example is a project that contains three pipelines. Pipeline A spawns pipeline B in STAGE 1 and continues to run, and STAGE 3 depends on pipeline B completing, so the paths merge. Pipeline B spawns Pipeline C at STAGE 1 and continues to run, and STAGE 3 waits for Pipeline C to complete before continuing. In this way at STAGE 3 of Pipeline A, all three pipelines merge to complete the release.
-
A release contains three separate independent applications, and each pipeline is triggered autonomously by its team. For the release to complete, these independent pipelines must converge when completed.