CloudBees Flow Release Strategy Update

Original Creation Date: 2014-08-28 00:27:34 UTC

NOTE - the release strategy was updated in 2020 as seen in this article:  2020 Flow Release Strategy

We are excited to announce an update to our release strategy. We have realized that some customers like to take advantage of newer features at an accelerated pace. Instead of making every customer wait for 9-12 months for new features, we are introducing a new release type called ‘Feature Release’(FR). These feature releases allow us to deliver additional capabilities to our customers at a faster pace. Such releases would focus more on innovation and hence will have a bias towards new features. Though these are produced in shorter cycles, they are production quality and customers could put into production if shorter upgrade cycles are something they are comfortable with. Customers can of course install these into test environments to try out the new features and provide feedback. Customers will need to upgrade to the next FR in order to get defect fixes. Unlike traditional releases, FR don’t have maintenance releases. Defect fixes will be available by upgrading to the subsequent FR.

With addition of this new release type, we will now have 4 distinct types of release outlined below.


1. Long Term Support (LTS) Release
The traditional “big” release that we have been doing are now called LTS Release. New LTS Releases are Major or Major.Minor (e.g. 5.0 LTS, 6.0 LTS) versions, released every 9-12 months. An LTS Release is identified by the LTS suffix. An LTS release is supported for a minimum of 18 months. This timeframe will be extended as necessary to ensure that customers always have access to two actively supported LTS Releases.

2. Maintenance Release (MR)
New MR versions are Major.Minor.Maintenance (e.g. 5.0.1, 5.0.2) versions, released approximately every 3 months or sooner if needed. MR releases are supported as long as their parent LTS Major.Minor version is actively supported (e.g. 5.0). An MR release typically contains defect fixes, and does not contain DB schema changes. In some cases, we might expedite an MR release.

3. Hotfix Release (HR)

Hotfix Releases are released on as-needed basis to address specific customer situations. Hotfixes are typically issued to address critical defects, which can cause production outages, security issues or have a severe negative impact to customers. They can be made available on any supported LTS, MR or FR as needed.

4. Feature Releases (FR)
New FR versions are Major or Major.Minor (e.g. 5.1 FR, 5.2 FR) versions, released roughly every 2-3 months. This rapid schedule allows us to deliver new features at a faster pace. If necessary, hotfixes will be made available for FR releases, however FR will not receive MR releases (maintenance releases). Instead, defect fixes and features will be made available in a subsequent FR release. All new features introduced in FR releases will get rolled into the subsequent LTS release. A customer who is on a FR is expected to upgrade as newer FRs are released. Hence for customers where typical upgrade cycles are once or twice a year, it is recommended to use LTS in production environment and use FR in test environment to provide feedback on new features.

Feature releases do not apply to ElectricAccelerator. In that sense all Major or Major.Minor versions (e.g. 7.0, 7.1, 7.2) are considered LTS with maintenance (e.g. 7.0.1, 7.1.1, 7.2.1) for ElectricAccelerator.


Release process 

This faster and regular cadence is made possible because ElectricFlow powers our internal release process as well. Every build of ElectricFlow goes through a standardized pipeline for build, deployment and release.

In fact one of the key steps in our QA process is certifying a new version by asking it to build, test and deploy itself! This ensures that every version is production tested before we make it generally available. As part of this journey we have identified the areas of the product that require additional test automation, we have tested and optimized our server and agent installation process to make it easier and more efficient for our customers when they go through the install themselves.

We also capture performance testing information for each build which we use to ensure changes to the system don't degrade the user experience. Performance information is also captured for each pipeline and release that is run, allowing us to review our products' performance as it builds, tests, and deploys itself.

Here are some screenshots of ElectricFlow powering ElectricFlow. 






Have more questions?


Article is closed for comments.