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. Dependencies can also be managed and controlled with this platform.
You can model a Release by defining the Release process that consists of
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, Editing a Pipeline Definition .
CloudBees Flow 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 Flow.
All objects in CloudBees Flow 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, you 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, see Release Definition .
To get a bird’s eye view of all the releases that are planned, active, or completed, see Release Dashboard . To view the bill of materials, see Path-to-Production View To view the pipeline’s progress during the Release run, see Pipeline Stage Summary . For instructions on how to set up objects in a release:
See Examples: Modeling and Deploying Applications to set up applications or microservices.
See 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.
See Pipelines to set up pipelines.
CloudBees Flow 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. See Reserving a Resource for Job Step Duration for more information.
|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
Controlling the Releases
CloudBees Flow provides these ways to ensure that the Release runs are successful:
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 Flow sends notifications to the appropriate approvers, users, and/or groups.
See Visibility and Status of Release Pipelines for an example process flow.
You can set Run if and Wait until conditions on stages, tasks, and gates in pipelines. See Pipeline Concepts for more information.
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. See Process Branching for how to set conditions on the transitions between process steps.
You can set preconditions on procedure steps. See Step—create new or edit existing step for how to set preconditions in 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 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).
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 Flow.
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. See Postp for more details.
Release Planning and Tracking
CloudBees Flow can capture planning data beyond just the planned start date and end date of the Release. For better planning and tracking, teams involved in a Release can capture planning data at a granular level. Release managers can analyze the release pipelines, get status 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 Flow, you can model, automate, and visualize dependencies across releases. You can use CloudBees Flow 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 Flow 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 Portfolio View
To view the Portfolio View for a pipeline, click the Pipeline Portfolio button 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. Click on its Waiting on icon to discover it is waiting on the `BillPay ` and `ICT ` sub-pipelines.
Pipieline 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 see at a glance pipielines waiting on an action and pipelines pending manual input.
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, click the Release Portfolio button 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; click on it to see 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 see at a glance release pipielines 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, click the indicated skip wait button to request a skip. You are asked for confirmation after you click a skip wait button.
The wait skip button is visible only to the users who are allowed to skip the wait dependencies.
ifdef::futureReleases or pipelines can have dependencies on other releases or pipelines, for example:
A Release can be comprised of a combination of applications each with its own release train
Pipelines can trigger other Pipelines for other teams
Unless sub releases have finished main enterprise release may not proceed to production]
ifdef::future[Need visibility into release hierarchies and dependencies] ifdef::future[At runtime, need visibility into the live progress of the entire hierarchy to understand status and delays] ifdef::future[Today there is no way to
trigger releases/pipelines from existing release/pipeline
wait for completion of release/pipeline]
ifdef::future[Releases in enterprises are made up of loosely or tightly coupled pieces. A release might comprise a combination of independent applications or product lines. Each application is developed by an autonomous team that independently work on the output. These separate release train ultimately need to converge to push out the full release.] ifdef::future[There may also be dependencies across the components developed by different teams. So the release might branch to different pipelines to deploy each component, but there will be different wait points to ensure that dependencies are met and subpipelines are completed before the release can continue.] ifdef::future[The hierarchical release functionality in CloudBees Flow provides the visualization that you need to model and view dependencies between hierarchical or connected pipelines or monitor running releases with hierarchical connections, identify conflicts, delays, and bottlenecks.] ifdef::future[Hierarchical releases mean that you do not need call procedures to start subreleases or pipelines and store the IDs, and then at a later task, call a procedure that waits for the subrelease or pipeline to complete before continuing. This feature means less scripting and trains maintenance, increases your flexibility in creating complex release, and enhances visibility into the entire release train, all pipelines, bottlenecks, and delays.] ifdef::future[==== High Level Design
Release can have one or more subreleases
Release should be able to start on or more subreleases
Release can have tasks that wait for the subrelease(s) to complete.]
ifdef::future[==== Configuring Subreleases] ifdef::future[Users will be able to configure subrelease in main release by:
Adding a task that starts or triggers a release.
Configuring a task or stage to wait for a release to complete
Directly adding a release as a subrelease from the release editor page]
ifdef::future[===== StartRelease task] ifdef::future[Users will be able to invoke another release from the pipeline by creating a "StartRelease" task. This task will capture information required to create or start a sub-release. While adding this task type, users will need to provide following details:] ifdef::future[====== In template pipeline] ifdef::future[The following information will be captured:
Subrelease suffix (main release name will be prepended)
Pipeline to use for the release
Project under which release should be created
Values for any pipeline parameters]
ifdef::future[When a template pipeline containing "StartRelease" task is used to create a release, then for each "StartRelease" task (across all stages) a subrelease will be created and linked to the invoking release. Since a subrelease pipeline can have its own "StartRelease" task, this lookup and creation will be recursive.] ifdef::future[Before creating a new release system will check if a release with specified name already exists. If it does, then a new release will not be created but the existing release will linked to main release.] ifdef::future[Users will be able to configure payload for the main release and each of the created sub-release.] ifdef::future[====== In release pipeline] ifdef::future[When adding a "StartRelease" task in a release local pipeline, users will only be able to select an existing release. Following information will be captured:
Existing release name
Release project name
Values for any release pipeline parameters]
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.