The Release module captures, executes, visualizes, and controls the life cycle of multiple application or microservice enterprise releases. Using the Release capability, outputs from multiple teams can be coordinated to produce a final release to be pushed to production. You can create a Release model consisting of multiple applications or microservices deployed on different systems, such as traditional, cloud, mainframes, and remote servers. You can then run the Release pipeline reliably and repeatedly until the software release is complete.
You can use the Release feature to deliver software releases through traditional methods where changes from multiple applications or microservices are bulked up and are released together as a unit through a pipeline on a regular cadence (schedule) such as weekly, monthly, quarterly, or other frequency. In such traditional scenarios, the Release capability allows you to manage dependencies between multiple applications or microservices. In addition, you can even use the Release feature to cater to Continuous Delivery-style releases where code check-in from a developer can traverse all the way to production through various pipeline stages and approval gates. The Release feature allows CloudBees Flow to manage all the releases in one platform, regardless of the release methodologies used by the release team. Anyone can quickly get a status of a release and then access the Release details. This information can also be used to troubleshoot and improve the software release process.
Visibility and coordination
The Release Dashboard , also referred to as the Release List , allows the release team to get a bird’s eye view of all the releases that are planned, active, or completed. For a specific release, you can easily see its status, what the milestones are, if the release is blocked for some human intervention, and the Release’s progress.
Path to Production (or what is where)
For each stage in the Release pipeline, the Path-to-Production view shows the applications or microservices deployed in the release, the deployed versions, and the environments to which they are deployed. The details in this view include the application or microservice versions, the snapshots, and the environments that are not in compliance with the bill of materials throughout the Release.
CloudBees Flow keeps track of the data from the multiple teams involved in the release. The Release feature captures, validates, coordinates, and tracks all the details in one place, where everyone can access the Release definition , bill of materials (which applications or microservices to release),the pipeline controlling the release process, and environment to use across stages, approval conditions, release configurations, and so on.
When the Release is run, CloudBees Flow automatically coordinates the pipeline information needed to deploy applications or microservices in each stage. If you need to add an application or microservice, change an application or microservice version, or deploy to a different environment, you need to change only the bill of materials. You do not need to revise the pipeline definition or pipeline tasks.
You can reuse the pipeline to deliver multiple releases of the same software.
The Release manifest , also referred to as the Release definition , specifies the release process flow for the applications or microservices to be released, which include:
The pipeline controlling the process.
The applications or microservices in the pipeline for multiple-tiered deployments.
How to deploy tasks and processes using run-time parameters and other settings, such as smart deploy and artifact staging.
Where versioned objects will be deployed (multiple-tiered environments).
The approvers for manual process steps, manual tasks, and pipeline gates.
You can launch multiple instances of a pipeline associated to a release:
You can navigate through multiple pipeline runs:
You can pass pipeline parameters when starting a release:
You can also select the pipeline stages to run in a release:
You can create schedules for releases. For example, where teams are responsible for each stage and they want to execute only the releases for their stage. With the ability to schedule releases and configure stages to run, each team can set up their own independent schedules that run on a particular stage. They can set a start date and can also make a release recurring (for example, daily or weekly).