This feature would make it possible to execute multiple deployments of releases to multiple environments simultaneously.
The UI would allow you to select multiple releases from different projects, and for each release, choose an environment to deploy to. This feature would solve:
In Octopus 2.6, we added the ability to select multiple environments to deploy to. While this doesn’t allow you to deploy multiple releases simultaneously, it does allow you to deploy a release to multiple environments easily, which is what many people in the comments were asking for. Since it’s hard to separate the two, I’m going to close this item to release the votes.
John Cruikshank commented
At Zywave, we built a tool to accomplish this using the Octopus API. We recently rebuilt it for the purposes of open sourcing it and learning some new technologies.
Adam Bezverkov commented
Unfortunately that's not at all what we were hoping for with batches and re-reading all the comments, its seems that most people were in the same boat as we are. We don't need to be able to release to QA and UAT at the same time, we need to be able to group a set of releases together (web, api, services, etc) for deployment at the same time. Did you open another story to cover that scenario that we can move our votes to?
Matthew Grogan commented
I don't see this feature(s) in the roadmap which is a shame. We would *really* like to see this. We have optimized the rest of our continuous delivery pipeline by running builds and tests in parallel and now the deployment steps (using Octopus) between build and test environments and to production are taking by far the most time. There is also quite a large window of time where our services can be in inconsistent states.
Matthew Grogan commented
Echoing various comments below:
1. We also have multiple IIS websites (/services) that we wish to deploy either as a full set or some subset.
2. We want to be able to roll-back that set/batch in one go so the system is in its previous state
3. We would like the deployment of these websites to happen in parallel for speed
4. And once all websites are in place in their new versioned folders we would like all websites to be switched over in one go to minimize the window where there are inconsistent services running
Wayne Brantley commented
I think initially it is just a quick way to deploy or promote a release to multiple environments. This issue gets much worse when you add the planned multi-tenant feature. So, perhaps you look at implementing this when you do mult-tenant? https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/5730598-support-tenants-as-a-third-dimension-to-deployment
Anton Swart commented
My request for this feature is quite simple.
I would just like the option to select a release and then instead of the Select box where you select one environment to deploy to, I would like a checkbox list to select multiple environments to deploy to.
My usage case is that my multiple Environments represent standalone installations of a system. So if I am comfortable with releasing to all Environments being able to tick multiple options and pressing deploy would be a great help.
Along these lines, it would also be superb if on the Dashboard it was possible to see how many revisions behind an Environment is.
So if I only auto deploy to my Test environment, then the other environments would show something like "3 releases behind".
Also a while ago I've seen discussions of adding the Time to the deployment on the dashboard, and also compressing the dashboard view. Previously I hacked the html to achieve some of these things - maybe a custom css file which is not overridden on updates could help achieve some things like 'compressing' the UI.
George Vanburgh commented
Similar to other comments already posted, we have a system which consists of multiple Windows services, each of which is contained within its own NuGet package. Each release contains the latest version of all the services that have been changed since the last release, meaning the list components we wish to deploy are not consistent across all releases.
The ideal-world scenario for us would be for each of these packages to have its own Octopus project, and for to be able to select multiple projects for release. At the start of the sprint, a blank release would be created. Developers within the team would then be able to mark packages they wish to be part of the release, by adding the associated project to the release. At deploy time, Octopus would run only the projects which are part of the release.
Adam Bezverkov commented
We are still evaluating the product, but as others have stated, the environment we work in has many windows services, internal/external web sites/services, and db projects. We don't always deploy them all at the same time, but the group of projects that is deployed to test for a given deployment is promoted through to staging and production, so being able to promote would be very helpful.
Eric Hoch commented
Our releases consist of a mix of windows services, web services, web sites, and database migrations. We deploy roughly each month, but it is rare for us to deploy exactly the same set of projects each month. Having some sort of "Meta-Release" that the development team could prep to give infrastructure a single deployment would go a long way towards further simplifying our release process. Being able to set dependencies between projects and directly or indirectly deploying them in parallel would be a nice bonus as well.
My current plan is to script this with powershell and octo.exe, but having something baked into the GUI would make it more widely adopted.
Joe Waid commented
We're just getting started with Octopus deploy. We have a collection of several web services, windows services, websites and databases that form our product. For most of our releases we want to deploy all of these collectively to form a single release of the product.
However we have a need to support smaller patch releases that usually address specific bugs in a website or service. In these cases we need to deploy just a small subset of our larger release.
The question for us is how to structure our projects in Octopus to support this kind of usage:
1) A single big project that contains many steps to deploy many different services. This simplifies our deployments for full releases, but makes our patch deployments a little more complex to configure.
2) A project for each service, and for major releases we have to separately deploy each of them. to get a full release. This makes patches releases easier to configure, but increases the work in our doing our full deploy.
The problem that needs to be solved is how to structure projects in Octopus to support this kind of a model that allows us to have easy one button deployments of all our services and sites, while also giving us the ability to deploy specific projects as we need to, to address patch deployments.
Derek Trickett commented
Our current set up has a "full deployment" project where most of the steps are powershell script steps that use octo.exe to kick off other project deployments in a specific order. It does have a few steps of its own, mostly related to starting and stopping services. A batch with linked releases would be very useful - right now our workaround is to enforce all the projects to have the same version number. In our usage, we would promote a batch. Ideally the batch would have an independent version number from its linked releases that would represent a full "release".
Tom Parker commented
Not sure of the other uses of it, but IIRC our major use case for this was wanting to deal with situations where we wanted to release to a specific subset of a project group.
So, we had a set of projects, all in the same project group. Their versions are displayed as per the current Octopus display. However, we often want to release a subset of those projects. What the subset contains will vary from release to release, as we're often only changing some projects but not others. It would be nice to be able to create a "batch release" containing specific versions of specific projects, which can then all be released into an environment via a single button, rather than having to push multiple buttons, one per project.
Issues with existing Octopus methods to fix the problem:
- Single project with many steps, with a release containing already deployed versions of unchanged projects and new versions of changed projects: lack of visibility in the Octopus interface for what we actually changed and when.
- Multiple buttons: chance of accidentally forgetting one project in a given environment.
Steve Cole commented
Like others, we have several web sites (a user website, services, etc) that work together to form our product. A release needs each of these to be deployed before our product will work.
Our ideal scenario would be for Octopus to syncronise our batch of projects to get them all to the point where Octopus is ready to switch IIS to point to the new releases, i.e. wait for all projects to be ready to switch. Then Octopus would flick the switch for all projects in one go. The downtime would then be just a few seconds.