Make it easier to deploy a tenant-specific package that is versioned independently to the application

[michaelnoonan]

trafficstars

A typical scenario when deploying multi-tenant apps is white-labelling, where you deploy the application, and deploy the latest version of a tenant-specific styling package. It makes sense to maintain the tenant-specific styling in a separate repository, and increment versions independently to the main application - but Octopus doesn't currently make that easy to handle.

When building a release you can specify a variable like #{Octopus.Deployment.Tenant.Name} for the Package ID, but in Octopus 3.4.0 you are required to provide a specific Version - but the version will be different for each tenant.

What we propose is to add the ability to specify a Version like latest (similar to docker), and when Octopus resolves the package at deployment-time, it would use the matching package with the highest version number.

Alternatively we could support some kind of version range expression like NuGet's [1.0-2.0), or something like 1.0.* where * could mean latest.

The workarounds for this are not pretty:

• Add a specific package step per-tenant and scope it to that tenant by tag (we don't support per-tenant steps)
• Lock the per-tenant package version at 1.0.0.0
• Version the per-tenant package in sync with the application package
• Go back to project-per-tenant :(

UserVoice Suggestion: https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/15927640-allow-variable-version-for-packages-when-creating UserVoice Suggestion: https://octopusdeploy.uservoice.com/forums/170787-general/suggestions/6196811-nuget-version-wildcards-for-releases Source: http://help.octopusdeploy.com/discussions/problems/47266-dynamic-package-id-using-tenant-variable Source: https://secure.helpscout.net/conversation/244817397/9386/?folderId=557082 Source: http://help.octopusdeploy.com/discussions/questions/9120

[MarkSiedle]

More (recent) feedback on this issue re. wanting to be able to lock a package version to a given release version, which I believe we can do with the support for version range expressions mentioned in the description above (source: http://help.octopusdeploy.com/discussions/problems/47266)

[danielfischeroctopus]

Another Source: http://help.octopusdeploy.com/discussions/questions/11171

[tesharp]

Personally I'm not a big fan of using "latest". What is then the behavior when you promote a release? If I deploy tenant CustomerA to their Staging using their "latest" package that is fine, but when I then promote this to Production, do you pull "latest"?

[MJRichardson]

Make it easier to deploy a tenant-specific package that is versioned independently to the application

[pawelpabich]

We could show a list of packages, one for each tenant and select latest version by default. Then the user can adjust a subset of them if they don't want to deploy the latest version.

[JesperRisager]

"We could show a list of packages, one for each tenant and select latest version by default. Then the user can adjust a subset of them if they don't want to deploy the latest version."

That would be great for my scenario. We have to build a ClickOnce package for each ClickOnceHost, since the URL, it is downloaded from, is build into the manifest and can not be changed afterwards because of the certificat signing.

We used to have a process manually selecting each package (one for each environment), but I figured out I can do this:

Client.ClickOnce.Installer-#{Octopus.Environment.Name}-Dev

Which makes it so we only need one process which does wildcard on the EnvironmentName.

The problem is when we click Create Release, then we have to type in a version each time and 99% of the time we would like it to be the latest version.

[ccamburn]

@JesperRisager Not the full place to discuss this, but just to let you know, it is possible to alter ClickOnce packages post creation. We have a ClickOnce legacy package I had to support, and we build it a single time, and use a combination of tools to update everything. Base details below, and if you have additional questions, you can start a discussion topic on the Octopus Support forums and link it here.

Steps:

1. On deployment, we update variables in the UI of the ClickOnce site, run config transforms, and update info in the *.manifest and *.application files
2. Temporarily rename all files to remove the .deploy extension.
3. Run mage.exe -Update on the *.manifest file
4. Re-append the .deploy extension onto all files that previously had it
5. (Optional) Sign the *.manifest file with either the CertFile or CertHash using mage.exe -Sign
6. Run mage.exe -Update on the *.application file passing in the new -ProviderUrl and the path to the -AppManifest
7. (Optional) Sign the *.application file with either the CertFile or CertHash using mage.exe -Sign
8. Call the setup.exe file passing in /url=

I can share the script if you'd like, but this gets us around ever having to build the ClickOnce app multiple times.

[JesperRisager]

@ccamburn It sounds like your solution is superior to the one we are currently using. I would be VERY interested in any extra information and scripts I could see :)

[JesperRisager]

@ccamburn You can contact me here: "jrj systemate dk". Just add a @ and . in the blanks.

Hopefully thats enough to avoid spam bots picking it up... :)

[ccamburn]

@JesperRisager I greatly apologize for the delay. I missed the notification here, but here is the support thread. This should allow for public communication (in case anyone else needs it) and some back and forth for questions.

https://help.octopus.com/t/discussion-of-clickonce-packages/21647

[RobertLivermore]

I have a tenant-specific NuGet package to deploy for the application which contain resources specific to the tenant. The tenant may pay for addition enhancements which increase the version on the nuget package.

When creating a release assign an Octopus project variable to the nuget package select version, the variable will have the "Prompt for value" enabled? This allow the deploy package to be set at deployment time.

The other idea, keep it simple. New Octopus deploy step template. Expose the neget.exe install commands line argument. Just let us pass in the command line arguments and change the values with variables..

[blemasle]

This problem really cuts the whole point of using dynamic packages selection based on tenants. I do not understand the whole latest controversy either.

Tenants are already now at release creation time. So if I have two tenants A and B and a step using a package accordingly, wouldn't octopus be able to "just" select all possible packages based on the current state ? eg : release 1.0.0

• A.2.0.189
• B.2.0.158
• Common.2.0.789

Where 2.0.189 and 2.0.158 are the latest package available at the release creation time for tenants A and B respectively. It is still a "snapshot" thing, it would requires you to create a new release when you want an "update" and it would requires you to update the variables as usual on an existing release if tenant related variables change. So it does fit in the octopus way of doing things :)

This would solve a lot of use cases, and brings back the usability of dynamically selected packages, which is pretty pointless right now. Having to go to the package field, look for the latest available packages and then put that into the release creation form is a waste of time, is error prone, and do not fit the multi tenants release creation use case (what if some tenant package do not have the same version numbers as stated above), making a release unusable for certain tenants. Or worse, deploy an outdated source code...

[Marcus-James-Adams]

Just to add my use case to this.

I have a number of deployment's of applications that have pre requisites that must be manually deployed from maven or nuget. These package prerequisites are often version locked for a number of releases of the main product.

Currently I have to manually set them in the package details screen, every time we create a new release. If someone forgets its a bad release.

To have the ability to version lock a package or a jar installation in the process deployment step would eliminate this risk

[blakeduffey]

Is there any progress on this topic? We are looking to create a tenanted project where each tenant gets their own package. Each tenant package may have different unique version numbers.

[timshepherd-academy]

Any progress on this? It seems to be a fairly common requirement to be able to create a Release based on:

• the selection of a Tenant and then,
• the selection of a nuget Package - either selecting the latest via a specific tenant related Package Id or via manually selecting a Package

[timshepherd-academy]

bump bump anyone?

I did implement the workaround from here: https://help.octopus.com/t/dynamic-package-id-using-tenant-variable/1747/18 which is working however, it does mean that we are using the Channels system for a purpose for which it was not intended (I think)

[empz]

We're in need of this also. Any plans on implementing something like this?

[FinnianDempsey]

Additional request - Internal Link

[RobMcCarther]

Additional request - Internal