Specifying Nuget Package version in Octopus Deploy

Question

Basically I am trying to specify the Nuget package version on a step in a process in octopus.

We have a fairly straightforward process where we use Teamcity to create a Nuget package and upload it to the octopus, we then ask octopus to create a release for a given project and this fires off the Octopus process that installs 2 other nuget packages and then our new package that we just uploaded.

The problem we have is with the 2 other packages. I'll call them PackageA and PackageB. I want to install version 1.0.0.0 of PackageA and version 2.0.0.0 of PackageB and then always the latest for the NewReleasePackage I just uploaded. The basic step of Deploy a Nuget Package has a field for "NuGet package ID" which helps me identify PackageA and PackageB. However this doesn't let me specify a version. If I have two clients, one that uses version 1.0.0.0 of PackageA and another that uses version 2.0.0.0 then I will have two versions of PackageA in my octopus package repository and I need to be able to specify at the step level the version of the package I want installed for a given process/client. However I cant seem to find a way to do this. Can you help?

Thanks

Will

Answer 1

I'm assuming you're using the octo.exe to trigger your deployment through teamcity. What's unclear is how your deployment process is setup. So you're deploying three packages - of which you only want one to update.

You can specify the specific version of each package within your octo.exe call using the parameter:

package=StepName:Version

What you're looking for can be done, at the expensive of hard coded values within your octo.exe call. If packages A and B seldom change, it's not a problem. But if changes are made infrequently, you'll have to change the parameters for the octo.exe call.

It's all in the documentation on their website here. If you have more details, please provide them as my answer is highly speculative.

Theoretically speaking, I think there is an alternative option: break out the frequently changed NuGet package in it's own project within the same project group as the original project in question. This way, when you do a build and you're only deploying the one NuGet package to be deployed, as its the only change necessary to make.

By breaking up your project into two, you'll avoid the changing your script parameters altogether for the octo.exe - which, let's face it, is an ugly hack. It's not automating your deployments and ultimately making a hassle for yourself in the long run. If packages A and B don't change - why redeploy them with the one package that does change frequently? This is why I'm suggesting (without all the necessary info) breaking your project into two projects.

There are more creative solutions that I can conjure up, but the best practice/principle for deployment automation is the simpler and more autonomous, the better. When you're getting into the nitty gritty details about package versions for your deployments and only deploying the newest version for one package while sticking with the other older, static versions of other packages, it's time to rethink your deployment process as a whole from the ground up.