I have a case where I am merging and deploying an Azure IOT manifest file, which references several docker images, which are already published to an Azure IOT container registry.
tl;dr - I need to ensure that a release always contains the same parameters, but those parameters only become known at the time of first release.
I want to make a process that identifies the latest images available on the first release to Dev, but thereafter keeps those versions in this release, immutable for this release.
I have octoposh installed and see a reference to a ProjectVariableSetSnapshotId in the Release Resource. Can I use this to get a Variable Set and update the values I’m interested in? I thought this would be possible, but don’t see how.
I have also considered updating the Project Params, triggering a snapshot update from Project params, then putting the variables back again. I guess this is probably what I’ll end up doing, though it increases the risk that my versions will be polluted.
Or Double handling the manifest file, once on first run, then again with env params on deployment.
That is a very interesting question! There are a few ways you could achieve your objective, including the ones you mentioned. The problem with using variables to determine your versions is that unlike most parameters, variables are to some degree mutable for a given release, so it is difficult to guarantee consistency.
I would suggest splitting this process into two separate projects. The first (new) one would determine the versions or tags of the docker images you want to deploy, merge those into the IOT manifest file, and create a package from that manifest file which it uploads to the Octopus package repository.
The second (existing) project would then just take the manifest from that package and deploy as usual. You could configure automatic release configuration for that second project, and use a lifecycle that automatically deploys to development. You might use the “Deploy Release” step in the first project to start the deploy to development of the second project instead. The specifics are really up to you for whatever best fits your workflow.
If packaging the IOT manifest file doesn’t meet your needs, or you have other parameters you need to provide outside of the manifest, the first project could simply write all the relevant values to a JSON file or whatever you prefer to use, and package that instead. Then, in the second project, you could insert a script step at the beginning which reads that file from the package and writes the values it contains as Output Variables which you can use later in in the deployment process.
I hope this information is useful and that I’ve not misunderstood your question. Let me know how you go!
I’ve now implemented the solution as I mentioned I would likely go ahead with.
Specifically, update Project variables -> update Release snapshot from Project Variables -> revert project variables from their original values. I also update the release version to append these package build nos.
I have this process step in the same process, but since its scoped to only run on Dev releases, it only runs once. I think I could always do this, even if I go to packages, rather than daisy chaining releases, which would make maintaining my release notes harder.
Can you elaborate on what other processes might change the Release Variables? I think only an update from Project Variables, correct?
I will consider what you said, and I think the double handled manifest file may well be a safer option, going forwards. I hadn’t thought of creating it and other artifacts as a nuget package, that may be the best option going forwards. Actually looks like I may end up triple handling these things… may as well get used to it.
The only thing that will change a release’s variables once it has been created is if a user clicks the “Update Variables” button on the release screen. This compiles a new snapshot of the variables from all sources - project, library variable sets and tenants.
Good luck with your deployments, and please let me know if I can assist further!
