We’re re-architecting how grouped feature deployments work in Gearset Pipelines. Bundles are the next evolution of releases, bringing a cleaner, more flexible foundation to support advanced release management workflows going forward.
Migration to releases based on bundles will be done gradually over the next several weeks.
To check whether you need to do anything to prepare your releases for the migration to bundles, see the below section: Do I need to do anything?
What are Bundles?
Bundles are the new way to group multiple features together into a single deployment. You can validate, manage, and deploy them just like you would with releases - but under the hood, they’re built on a more scalable branching structure.
Releases will be powered by bundles and will retain all existing functionality and workflows.
Why are we moving to Bundles?
The current releases branching model has some technical limitations, notably the fact that it uses a single branch to handle propagations. This has previously stopped us from developing and delivering more advanced features customers has been asking us for.
We've redesigned the foundation to better support more advanced features, such as:
Removing features from a release in the future
Creating releases/bundles earlier in the pipeline
Propagating a release/bundle across environments as a single unit
While these advanced capabilities are coming later, bundles have been designed with adding these abilities in mind.
What's better about Bundles?
Bundle-based releases work just like releases today - but with a few key improvements:
Higher success rates when creating a bundle:
Even if some features can’t be merged cleanly, the bundle will still be created. Any conflicts are surfaced as open pull requests, so you can resolve them manually.No feature count limits:
Bundles no longer rely on storing feature lists in PR descriptions, removing any limitations on the number of features that can be bundled.Improved branching structure:
Bundles use two dedicated branches which mirrors the structure of feature base / promotion branches and provides a solid foundation for future functionality.
What changes in the branching model?
The main change with bundles lies in the change to its branching model.
Old release branches followed the format gs-release/<uuid>_-_<env>, where a single branch was used to both merge multiple features, as well as promote to a given environment. However, this had limitations when trying to deploy changes to multiple environments.
Bundles introduce two new branch types:
gs-bundle-base/<uuid>>_-_<env>- this is a copy of the environment branch (likemainordev) at the time the bundle is created. It acts as the base where all feature branches are merged and conflicts between them are resolved.gs-bundle/<uuid>_-_<env>- this is created for each environment the bundle is promoted to. It exists to resolve any conflicts between the bundle and that target environment.
This mode gives us more flexibility moving forward, providing you with even more benefits - which we will announce in the near future.
When deployed a bundle-based release is propagated in the same way as a classic release by creating back propagation PRs for individual features. At this point bundle base branch and bundle propagation branch are no longer needed, and they both are automatically deleted.
Do I need to do anything?
Switch to new bundle-based releases will be done gradually over next several weeks. The migration will happen automatically and doesn't require any steps from you.
If you use current release branch naming convention in configuration or automation, you may need to update them to support the new branching model (continue reading for more details).
When your team is migrated, all of your existing releases will remain fully usable and new releases will look slightly different under the hood, but the way you interact with them in the UI remains the same.
If you don't have any protection rules, configuration, scripts or documentation referencing the current naming convention for release branches (gs-release/*) the migration doesn't require any manual steps.
If you have protection rules, configuration or documentation referencing the current naming convention for release branches (gs-release/*) you need to update them to also support the new naming convention (gs-bundle/* and gs-bundle-base/*. See What changes in the branching model? for more details.
After the migration when all non-bundle releases have been deployed or abandoned the support for gs-release/* will no longer be needed.
How can I check whether my releases are using bundles?
All interactions with release in the app remain the same. You can see that new releases you create are using bundles by checking the release in your VCS. If the release pull requests uses gs-bundle/... branch as the source then it's a bundle-based release, if it uses gs-release/... branch then it's a pre-migration release.
Questions?
If you have any questions, concerns, or want early access to the bundles rollout, just drop us a message in the in-app chat. We’d love to hear what you think.