Something that seems to be generally missing for us is a way to communicate relevant data from a TFS build all the way to Octopus. This is something that will become more of an issue, once we move to automatic deployments to QAT with Octopus 2.6. A few examples that come to mind:
- A way to automatically take the resolved work items/included changesets from a TFS build and use them as Release Notes on the Octopus Release.
- A way to notify Octopus that we have changed to a new Sprint, and increase the major version number on the next Release creation in Octopus
Any ideas?
Hi Lonevvolf
Our API is the answer to all of those things if you’re prepared to modify your team build. We have customers who do roll up work items into an HTML document and pass them in as release notes and it works quite nicely.
You could do something similar for your #2 but typically people use their build system to determine build numbers and Octopus picks up those from the package.
We’ve added support for pushing release notes in from OctoPack, but doing both of those items as you suggest would be making too many assumptions about our customers build processes, and would be overly prescriptive for the large majority.
Hope that helps explain some of our thinking.
Regards
Damian