You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 6, 2023. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: