0

I'm looking for a way to achieve something like this using VS online ...

I have a lot of small solutions in the root of the repo that are structured a bit like ...

Foo.sln
   "/Framework/xxx"
   "/Foo/*.csproj"

Bar.sln
   "/Framework/xxx"
   "/Bar/*.csproj"

... There are generally some common pieces in each of the solutions that are shared but each solution also contains the solution specific pieces.

I would like a way to be able to setup a CI build that can determine what solutions the code changes are in and do an appropriate Gated CI build but not build anything else.

Is this possible, if so how?

I have been able to setup a CI build that builds everything no matter what gets checked in but i'm thinking that what I need is some sort of build def that picks "sub builds" to actually run by looking at the files checked in.

Or maybe you guys have a better way to achieve this (maybe using powershell to query the changeset via api or something)?

  • Are you having performance problems with lengthy builds? What is the motivation for a partial build? – Robert Harvey Jul 26 '16 at 15:22
  • I want check ins to be gated and CI built because my team can't be trusted to not break the repo and the boss seems to think that branching is a bad idea (out of my control) ... it's a means to ensure we are productive and not waiting around for a full build (around 15 mins) – War Jul 26 '16 at 19:12
  • Is the cure worse than the disease? – Robert Harvey Jul 26 '16 at 19:49
  • well longer term I would like to turn off the gated check in but it still makes sense to have a CI build, and why CI build everything if only a small part of the repo is affected? – War Jul 26 '16 at 20:12
  • It's about making sure we don't re-build and deploy stuff that has no changes so we can handle any problems sooner otherwise we have devs sat around for 15 mins (or longer if there's a queue of builds) instead of 1 to 2 mins for the smaller builds. Do you think this is the wrong way to approach the problem? Should I just build everything and push harder for branching, then gate the main branch only? – War Jul 26 '16 at 20:20
0

Ok had a discussion with the team and have come to the following conclusions ...

  • Branching will be introduced in to TFS
  • Gated check ins will be applied to "non working branches"
  • CI builds, with gating will build everything and execute all unit tests
  • Working branch(es) will CI build but not be gated to give visibility or issues to the dev team

The net result is that I don't need to worry about what's in the check in that just took place nor do I have a time issue with devs / testers being sat around waiting on builds.

After digging around in the MSDN documentation I came to the conclusion that trying to have more granular builds was not reasonably achievable without a lot of work on TFS so this feels like the cleaner approach to achieve the same result.

  • More granular builds aren't difficult at all. You just have to specify what directories to build and what directories to monitor for changes. Whether or not doing that is a good idea depends very much on the nature of your code base. – RubberDuck Feb 22 '17 at 22:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.