I have an application which consists of the main .exe (and associated .dlls etc, bundled as an .msi) and client-specific configuration files (bundled as a client-specifically named .zip file). For each client we install the same exe, but they only get their specific configuration files. None of these deployments happen automatically - they all require manual intervention so I’m thinking just dropping the release artefacts in a drop folder ready for the customer support person to copy and install at the client.
The tricky bit (that I’m not sure is supported yet) is the client-specific configuration files.
For each release version of the main application .exe, I’d like to offer an associated release for each client configuration, but allow the customer support person to choose whether to deploy that release (and so create a log of what version each client is using).
I had thought tenants could be a way of providing the client-specific functionality, but they don’t seem to allow you to create releases with the same version number for different tenants.
Thanks for getting in touch! The release/3.4 refers to the release that the ticket is associated with. In this case, Tenants were release in Octopus version 3.4. The enhancement itself is still on the to do list.
The GitHub issue you linked is the relevant one. Unfortunately, there are no other options available here but the work around listed in the issue. I will add your ticket as another source for the developers to see.
Let me know if there is anything else I can help with.
Ok so it is on the to-do-list. Does that mean that it is scoped for a specific future release? I ran into this problem when trying to migrate an application (one application 70+ customers) using project-per-customer. It turns out that their build process spits out unique packages for each customer and sometimes unique version numbers for each package. Some of the packages could easily be merged into fewer packages and handled as Tenant-configuration variables but not all of them - at least not easily.
Thanks for getting back. I’m sorry for the delay in responding to you. That does mean it is scheduled for a future release. When exactly that is, I can not say, as this will require quite a bit of planning and work to achieve. However there is a decent amount of people running into this same problem. Unfortunately, the only option available currently is the messy work around listed.
Let me know if you have any further questions here.
Is the backlog shown at. https://waffle.io/octopusdeploy/issues ordered in terms of priority? I can see that 2755 is on the list but quite a long way down. If the timeline is lets say +6 months for this feature, then we would have to rethink the entire merge and come up with some other strategy.
It looks like you have found one of our old issue boards. Our list of open/closed issues is our GitHub page. The board you linked to has the same content but is not used internally any more. And it’s not used as a prioritization list. Here is the link to the GitHub page: https://github.com/Octopusdeploy/Issues/issues
Generally, we prioritize our issues on the impact and severity. We tend to not immediately prioritize issues that currently have workarounds. The issue is still on the to-do list and will be worked on but it is not currently on our road map.
