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.
Bundles are not yet available to all customers - if you would like to get early access to bundles let us know in our in-app chat!
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.
As of today, releases will be powered by bundles and will retain all existing functionality.
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:
Adding/removing features from a release in the future
Creating releases earlier in the pipeline
Propagating a release 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?
Bundles 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.
What happens to existing Releases?
We’ve designed the migration to bundles to be as seamless as possible to avoid disrupting your workflows.
Thus, when you migrate to bundles you can continue working with your existing releases exactly as before. However, any new release you create will now use the new bundle format instead.
This transition is automatic - no action is needed on your part.
What if Bundles don't work the same way as Releases?
If anything doesn’t feel right or isn’t working as expected, we want to hear from you. We’re actively collecting feedback and continuously improving the experience.
In the unlikely case that bundles aren’t working for your team, we can temporarily disable bundle-based released and move you back to the classic releases workflow. This takes seconds on our end, and you’ll be able to continue your work without interruption. Simply abandon any bundle-based releases, and create a new release - just like before.
Do I need to do anything?
All of your existing releases remain usable. New bundles 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 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 do I get enrolled?
We’re rolling bundles out gradually. If you’d like to get early access, just reach out to us via the in-app chat - we’ll get you up and running in no time.
What happens next?
We’ve already begun rolling out bundles to a small number of teams. We're working closely with them to gather feedback and make final refinements.
Once we’ve validated bundles at scale and ensured everything works smoothly, we’ll move to general availability and begin enabling them more broadly.
Stay tuned — and let us know if you’d like early access!
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.