Skip to content
This repository has been archived by the owner on Apr 6, 2023. It is now read-only.

Dynamic versioning of locally built packages #109

Open
swn1 opened this issue Jun 15, 2015 · 0 comments
Open

Dynamic versioning of locally built packages #109

swn1 opened this issue Jun 15, 2015 · 0 comments

Comments

@swn1
Copy link

swn1 commented Jun 15, 2015

OK, this is going to be a big "blue sky" feature suggestions but I hope the code isn't too bad in the end.

I'm in the process of breaking up a massive monolithic build, O(5e6) SLOC in O(300) projects, with a substantial number of third party components integrated at anything from the install-on-dev-machine to source-mixed-in levels. I'm making good progress, relying heavily on coapp.powershell, but versioning is becoming "a thing".

I contributed a task to Mike Fourie's wonderful MSBuild Expansion Pack; the TeamBuild task (in the TfsYYYY namespaces) was designed mainly so I could query for the drop folder associated with the most recent successful build, by build definition name. Using that I wrote a couple of custom build steps in VS2008 to pull a couple of separately build components into our main build dynamically. Those are part of what I'm updating to VS2013 and nuget now.

What I'd like to do is to make some kind of notation when binding a package to a project (or better, at the solution level) that says "get latest". Then when we head into a release I want to be able to pull one plug with a big red banner on it ("remove before flight") and check in with specific versions locked down.

If the process could be wired up so we can find the dynamic packages by drop folder and then switch to the preset approved server for the locked-down versions, that would be fantastic. I'd rather not be compelled to push daily (or CI) build packages onto the approved nuget server. I guess one option would be to run a separate server for ephemeral packages and then push the ones that end up in a release to the "forever home" server. That would work too, but it's an extra copy and an extra data retention policy; keeping it in the drop folder leverages the Team Build retention policy mechanisms.

While we're at it, is there a "best practice" for package version numbering via team build? So far I've been doing all the package building by hand, checking in autopkg files with manually updated version numbers along with whatever else changed. But that needs to go lights-out soon.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant