Hi there,
Since we are having two teams working on same app and sharing environments, we have a few questions regarding to this as listed below.
-
what do you suggest for handling app dependencies? for example, when installing application A, it can check if App B, which has been configured in another project, has been installed. If B has been installed, then just skip this step, if not, it can trigger project B to install App B. hope it making sense 
-
We have two channels for installing two instances of window service on same box. The default channel is our master channel, which is stable version. the issues now is we can not see which version is installed by default channel after we have quite a few deployments in Branch channel.
-
how can we track the version on each machine within same environment if we just did a partial deployment. the dashboard only shows the most recent one, even though only 1 of 3 machines has been deployed to.
-
is there a way to duplicate variables sets?
-
say we have a brand new server, and we want to install application A, B and C and even more. after we add the server into environment and assign roles which needed for these apps, is there a way we can install all of these apps together instead of triggering deployments one by one? and later we can use the same way to keep all these apps to latest version.
Thanks in advance, looks like i have put more than a few questions here
Regards,
Ben
Hi Ben,
Thanks for getting in touch! Let’s get straight into it!
1. App dependencies
Personally I try very hard to make the dependency relationship between applications “version tolerant”. That way there is seldom the need to ensure A ships before B, and when the need arises I’ve done it manually.
There is nothing built in to Octopus that will help you with this: every situation is slightly different. Some of our customers have built “orchestrator” apps that sit above Octopus and drive it’s API. Some other customers in simpler situations will have a step in their process which calls the Octopus API, checks dependencies, deploying any that are required, and then continuing with the deployment.
2. Better visibility of releases in Channels
I agree, and we want to build a better view for this information. We are planning to make this better in Octopus 3.4 as part of the overhaul we’re doing for dashboards and multi-tenant deployments. We will be paying attention to Channels as part of this work.
3. Partial deployments
Personally I try to avoid per-machine or partial deployments into environments wherever possible. I prefer to think at the aggregate level of Environment, Role, etc rather than machines: treat machines as cattle, not pets.
At this point Octopus isn’t very friendly when it comes to knowing which release of a project is deployed to a specific machine. In Octopus 3.4 we are hoping to make this easier as part of the elastic environment environment and transient machine support. We are planning to record which releases are the latest deployed by Octopus to each machine, and then display this in the right places.
We are also hoping to improve the dashboard views to make it clearer how many machines have been deployed a certain release. Watch this space!
4. Duplicate variable sets
No, there’s no built-in way to do it. I would recommend using the Octopus.Client to build a simple script (perhaps with LINQPad) to help you with this.
5. Auto-deploy latest release onto new machine
Keep your eyes on Octopus 3.4 - we are building this features right now. Read the early RFC and keep in touch with the Octopus 3.4 EAP so you can add your feedback!
Hope that helps!
Mike
[image: Mic Drop]
Hi Michael,
Thanks a lot for your help. we are more than happy to look forward the next
release 
Regards,
Ben
Hi Ben,
Thanks for getting back to me, and it does seem like 3.4 will be a good release for you. Like I said, get involved in our EAP so you can be part of making Octopus 3.4 great!
Happy Deployments!
Mike