From this page we understand a serious limitation of Octopus is that “deployments of the same project to the same environment (and, if applicable, the same tenant) are not able to be run in parallel”
This is a perfectly normal scenario for us, where we have hundreds of different SSRS reports and one automatic deploy project “Deploy SSRS report”, with a manual intervention step Proceed/Abort at the DTAP Acceptance environment. Today we are releasing new versions of some thirty reports, and by this limitation they need to be handled one by one. We have other projects that fit the same scenario such as “Deploy files” and “Deploy database script”.
When can we expect Octopus to support concurrent deployment of multiple releases of the same project to the same environment?
Is it on the roadmap?
Hopefully the answer is not that we should create 245 separate projects, one for each report…
One thing is parallel running of deployments of the same project to the same environment. This is in fact not what I’m referring to.
Another completely different thing is having multiple concurrent releases of the same project being deployed on the same environment and in a paused state e.g. awaiting a Manual Intervention (Proceed/Abort) step.
The latter has so far always been possible in Octopus, fitting well with the described scenarios, but appears to have been broken by a recent change in Octopus 2019.5.8.
I believe I understand your scenario. And I can see why this change has caused a problem for you.
For a little context, we had a number of customers for which the previous behavior of allowing a concurrent deployment to start while another was awaiting manual intervention was causing problems.
And given the primary use of Octopus is deploying applications, we agreed and implemented the change.
We hoped the change wouldn’t negatively impact anyone, but unfortunately it evidently has.
I’m raising a discussion with the team to see what we can do to improve this for you.
It’s interesting, your scenario isn’t deploying an application, but rather running a job.
This doesn’t help you right now, but we are working on a feature called Operations Processes which will be specifically designed for running these types of tasks.
Thanks for your reply.
I’m not sure where you get the idea that in this case we’re not deploying an application but rather running a job? What is your definition of an ‘application’ and that of a ‘job’?
We have several IIS applications and their Octopus deployment projects. Of each application we may have more than one version simultaneously on each environment. Part of these applications, and that we have separated out, is reporting, which offers our users a myriad (hundreds) of reports over their data. Each report is developed, versioned, deployed and tested independently from the IIS applications and consists of an RDL for SSRS plus one or more supporting database scripts. That doesn’t sound like a ‘job’ to me.
Our deployment project for SSRS reports is currently as follows:
I do not understand why you think this is running a job and not deploying an application.
This project is deploying different reports in different versions to SSRS servers in different environments.
The only special thing we do is we use the major version as a report numbers. This is the mean reason why we are deploying a lot of different versions of this project at the same time.
But this is not the only project impacted by your recent change of to block multiple deployments to 1 environment using manual intervention.
Also for our IIS application we are sometimes deploying multiple versions at the same time (for use with specific groups of users)
I can understand that for some of your customers blocking deployment on a manual intervention would be beneficial, but for us this change is really disastrous, potentially forcing us to rethink and rebuild our deployment processing.
To avoid this conflict, maybe you could make “block deployment on manual intervention” a setting (per project) or a setting of the manual intervention step.
We are a paying customer for quite a while now. We were really taken by unpleasant surprise by this sudden and for our organization breaking-change by Octopus which appears to have been made on behalf of just one single customer. It really does break many of our deployment processes in quite a paradigmal way.
Could we please have some feedback on this serious issue? We’ve taken the effort to offer a constructive suggestion as a way forward and which in our opinion would serve all.
We are going to implement a checkbox on the manual intervention step which will support the previous behavior. Here is the issue which you can track. And if you have anything to add to the issue, I encourage you to.
We will get this implemented as a priority.
Again, we do sincerely apologize for the inconvenience.
This reverts the default behaviour, and provides a switch on the manual intervention step for those who wish deployments to block.
Again, we are truly sorry for the disruption to your workflows.
Please don’t hesitate to reach out if anything doesn’t appear as it should after upgrading.
