Create Release with Specific Snapshots

Legacy Execution
1

The SwaggerUI for Create Release shows that it’s possible to specify a ProjectVariableSetSnapshotId and a ProjectDeploymentProcessSnapshotId.
My colleague and I tried to take advantage of this to create a release with old variable and process snapshots, copied from an existing release, in order to be able to hotfix production (the variables and process have changed too much that the latest deployment process and variables are not compatible with the version of the software we need to hotfix).
It appears as if the API ignored these values and just used latest process and variable snapshots. Why does it allow us to specify these values if it’s going to ignore them?
At the moment, we are reusing the old release with updated packages to accommodate production hotfixes. This can be confusing to track which tenants have received the deployment, disparities between release name and packages, etc. There must be a better way. Please advise :slight_smile:

2

Hi Rob,

Unfortunately this looks like it’s a shortcoming of our Swagger feature, as these fields are actually “read-only” and automatically populated when the release is created.

What you should be able to do:

  • Create a new release,
  • Retrieve the newly created release and
  • Update the ProjectVariableSetSnapshotId and ProjectDeploymentProcessSnapshotId on the newly created release

Not sure if this way makes your life any easier, but I hope it helps.

Thank you and best regards,
Henrik

3

Hi Henrik,

Thanks for the quick response.

This also does not appear to work. The default values for ProjectVariableSetSnapshotId and ProjectDeploymentProcessSnapshotId persist even after updating the release through the API.

Rob

4

Hi Rob,

My apologies, I misread the code and even contradicted myself saying the fields are read-only but suggesting you could update them :frowning:

Our general recommendations for this situation would be to use channels to split your deployment process into a “current” and “vnext” type process so you could still do hotfix releases to your production environment while your other environments move on to the new process until it is ready to be moved to production.

Unfortunately, I don’t have a better solution than the one you are currently using.

My sincere apologies for the inconvenience caused by this.

Thank you and kind regards,
Henrik

5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.