A couple questions regarding Package Metadata / Work Items:
Until such a time as Azure DevOps package metadata is supported, is it possible to create custom metadata files and push those to Octopus myself? It would allow me to still get some of the benefits of the feature until such a time as the extension is working. It would also allow anyone using non-standard source control to manage work items between releases.
In terms of the “roll-up” feature of package metadata, how does that interact with lifecycle retention policies and the built-in package feed retention policies? For example, if I am going from version #2 in Production to version #30, the deployment is supposed to be aware of all work items between those releases, but what if releases #3 though 10 were deleted because of the lifecycle retention policy? What if the packages were also deleted due to built-in feed retention policies?
Any update on the Azure DevOps extension and when we might expect that to have functional work item linking?
We haven’t yet upgraded to the latest versions of Octopus. Is there a demo environment showing these features, especially with any API / swagger views to show off these features? It would go a long way toward preemptively writing api scripts related to metadata, as well as showing the UI to management. I noticed the official demo environment of https://demo.octopusdeploy.com was still on 2019.1.0.
On 1, this isn’t really viable with the default functionality. The package metadata is build around the workflow of passing commit messages to Octopus, so building the content yourself isn’t trivial. Which source control are you using? Given the demand, we’re targeting Git, so Azure DevOps Git will be supported. If there is demand for other providers we’d be open to looking at support for them.
2, this is a really good question, and a weakness we are currently aware of. So yes, if there are many versions in between releases it is possible that some could get removed by retention policies. We have been working through some possible solutions around this, to keep a permanent record of certain release and deployment information (there are other drivers behind wanting this data kept too)
3, the ADO plugin relies on a number of components coming together. The we’re part way through completing the review on the last couple, so it should be a matter of days.
4, your best option might be to get a trial of the cloud version of Octopus, it uses the latest version and could be used to demonstrate the work item features. The demo site is quite deliberately locked on that version at the moment.
Thanks for the updates. We’re currently using mostly Azure DevOps TFVC repositories. Some are git repos, but migrating from the existing TFVC ones to git isn’t entirely trivial.
In regards to #2, is the info currently based on the package existing, the release existing, or both? If it’s only one and not the other, we may be able to find a way to adjust retention policies accordingly, but if we’d need to keep every release and every package it’s likely too much for us to keep.
Also, thanks for the suggestion of the trial of the cloud version. I think I’ll hold until the ADO plugin update, and once that’s done, I’ll throw the trial together and use it to demo.
RE 2, more the release existing. The BuiltIn feed’s retention setting is taken into consideration, whether the packages are actually in the builtin feed or an external one, and then older package metadata which isn’t being referenced by a release is removed. “Older” is based on 100 days or the BuiltIn feed’s retention setting, whichever is the lesser.
So you’d need releases to be retained for long enough to cover the time between deployments to the last environment in your life-cycle (e.g. Production).