I have a child project that contains a single “Deploy a Release” step. When creating a release within the child project, the targets are not visible, even though they are clearly visible at the parent project.
Parent Project:
Child Project:
Hi Todd,
Thanks for getting in touch, I appreciate your patience.
In the deployment preview section, we show the machines that each step will execute on.
The Deploy Release step doesn’t execute on machines (as it runs on the Octopus Server) so it doesn’t show the target machines.
Whereas the Deploy Package step does execute on machines, so it will display each of the machines it’s going to run on, in this scenario DEVOPSVB16
I hope this helps!
If you have any further queries please let me know 
Kind Regards,
Reece
We have seen this issue as well… I understand the primary task runs on the Octopus server but what I care about is the deployment that the server task will ultimately trigger.
Here in the child project we have no idea that the nested Deploy A Release step will not succeed:
Knowing that WEB01 is offline is important at the time of deployment creation:
Reece,
If I had several Release projects being grouped into a single Deploy project, I’d have no control or visibility into what was about to happen or not happen. Adding some additional step that will execute against my target role will bring that visibility in, but what happens against the parent Releases? For instance, what happens in this example where I add step that executed against the targets and I exclude a target? Will that target also be excluded in the Parent Release projects when they execute?
No. Excluded machines will not flow through to the triggered child deployments.
Unfortunately you are bumping into limitations of the feature. The Deploy Release step isn’t special from the point-of-view of the deployment page.
I completely understand the behaviour you are expecting here. And we potential could display the deployment steps from child projects, and allow including\excluding machines from them. One potential issue is that there is no limit to how deeply these can be nested. i.e. A project can have a Deploy Release step which deploys a project containing a Deploy Release step which deploys a project… But that’s just a UI issue.
I have created a UserVoice suggestion for this functionality, which I encourage you to cast a few votes for. I’ll discuss this with our team.
In the meantime, if you wish to include\exclude machines, you’ll need to deploy the child projects individually. Or remove the appropriate roles from the machines you wish to be excluded prior to deploying.
Regards,
Michael
Thanks Michael.
Another shortcoming to the Deploy a Release step is that it seems that Deploy A Release steps cannot be added to a rolling deployment. The Deploy A Release step sounded so good from an organization standpoint, but we’re really struggling to find any way to incorporate it into our deployment workflows.
Rolling-deployments (as you know) are used to run a group of steps together on each machine in a role. We assumed you wouldn’t want to trigger a deployment for each machine in a role, and so we didn’t allow the Deploy Release step to be a child-step. But this decision can be easily changed. It’s entirely possible we overlooked some scenarios.
Would you mind explaining your scenario in a little more detail? I’m sorry to hear this step isn’t fulfilling your expectations, and we are certainly keen to help any way we can. If you think it would be easier to discuss via video-chat, I’m more than happy to arrange a time? Alternatively if you’re happy to discuss here, that’s fine too.
Thanks Michael. I’ll try and explain. If it’s not totally clear, or if you want to discuss over a call, we can certainly arrange that as well.
Take our web farm for example. We have a group of web servers that all sit behind a load-balancer. We need to deploy to each server individually, and completely, without taking down service to our clients. For this, we use a rolling deployment that cycles through one server at a time, removing each server from the load-balancer and draining all active connections. We then gracefully stop any needed services, deploy our updated packages, start services back up, and then then run some automated verification steps before returning the server to the load-balanced pool. All of this orchestration needs to occur on the child deployment project and not upstream on the parent project because we deploy several packages and each one of them cannot include steps for interacting with the load-balancer. That would not only be inefficient, but it may also cause problems whenever packages are dependent on each other.
What’s great about the Deploy A Release concept is we would no longer need to duplicate deployment steps between individual package deployment projects and complete deployment projects where we wish to deploy all packages at once. It also gives us absolute visibility into knowing which version of each package was deployed without trying to figure out which project was used for the last deployment. I sure hope that we can figure out how to make this work. Please see the diagram for a basic look at our deployment structure.
Todd,
That’s a great explanation. I think I completely understand now. We actually didn’t anticipate the Deploy Release step being used in this way, but it’s a neat idea.
The bad news: Right now, it isn’t possible.
The good news: I’m very keen to make this work for you, and I don’t foresee any reason why we can’t. I’m going to attempt to implement this issue in the next few days, and it will hopefully be available next week.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.