How can we improve Team Services?

Provide build configuration dependencies in TFS Build

Provide the ability to create build configuration dependencies such that the success of one build configuration can trigger another build configuration such as a successful build triggering the building of an installation package or a build configuration which deploys to a development or staging server. Other tools such as Cruise Control.Net and Jetbrains TeamCity already offer build configuration dependencies/build configuration triggering through various means, therefore, TFS Build should also provide this type of support.

2,324 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    vs2015junkievs2015junkie shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    40 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • MichaelMichael commented  ·   ·  Flag as inappropriate

        I vote for it too as this will be a great feature as it will really leverage the power of TFS further.

      • HaukeHauke commented  ·   ·  Flag as inappropriate

        This is a crucial feature for the usability of the build engine. It should also be possible to use the artifacts from one build definition in the another build definition.

      • TimTim commented  ·   ·  Flag as inappropriate

        Please add this feature! This is a major roadblock for our team.

      • TkuTku commented  ·   ·  Flag as inappropriate

        Could you please give us an update when this feature will really "planned"? This would be great. We can't wait to somehow set up a kind of build chain for the TFS. Thanks!

      • TimTim commented  ·   ·  Flag as inappropriate

        When can we change "PLANNED" to "STARTED"? It is about time... I still and really cannot believe that this feature is still not implemented. Not even the slightest support. Just unbelievable! Sorry, but this is frustrating...

      • ClaudClaud commented  ·   ·  Flag as inappropriate

        We use custom activity for that feature that should be done long time ago. Post build powershell script could be used as well. True is it should take about an hour for a developer to add this feature and just testing.

      • Jon MillerJon Miller commented  ·   ·  Flag as inappropriate

        This is literally the last thing stopping us from migrating to a TFS build system. Currently we use CruiseControl.net have a few library projects that get built and then we trigger all projects that depend it on it to rebuild.

      • John BäckstrandJohn Bäckstrand commented  ·   ·  Flag as inappropriate

        This is the most important feature we are waiting on for us to be able to migrate from XAML, and onto vNext, although I guess this suggestion was originally for XAML-builds? This is actually fairly easily solved using XAML, there is ready-made code that is easy to find if one wants to.

        We do a regular build, with some unit tests. But then we have a created a test framework that tests our embedded code on actual hardware, and that is done as a separate build. The build can take 2 hours, and the test might take 3 hours so separating them is nice, since that way you can easily re-trigger a test for an "old" build, without the associated buildtime.

      • John BäckstrandJohn Bäckstrand commented  ·   ·  Flag as inappropriate

        This is the most important feature we are waiting on for us to be able to migrate from XAML, and onto vNext, although I guess this suggestion was originally for XAML-builds?

        We do a regular build, with some unit tests. But then we have a created a test framework that tests our embedded code on actual hardware, and that is done as a separate build. The build can take 2 hours, and the test might take 3 hours so separating them is nice, since that way you can easily re-trigger a test for an "old" build, without the associated buildtime.

      • MortenMorten commented  ·   ·  Flag as inappropriate

        Will it also be possible to use this in Git branch policy, to trigger as part of the validation of a Pull Request?

      • BrianJCBrianJC commented  ·   ·  Flag as inappropriate

        I added this years ago but the piece I'm missing is seeing these dependencies visually. The Project Managers/Devs need to understand how all the builds are linked. Please consider this as well.
        By adding Properties for chaining builds (true/false) & vNextBuild (TeamProject\BuildDefinition) to the build definition then adding a step at the end of the build that checks that this build was successful and the Property is true, then you can kick off the vNext build in the Chain (or as many as you want). We even have another property that allows us to keep the version number the same for all of the chained builds (I'm not a fan of this one). We have a powershell script that quickly shows folks the status of all the Chained builds.

      • Greg PakesGreg Pakes commented  ·   ·  Flag as inappropriate

        @Peter Anderson

        Why don't you just create a new build to run in the morning that only runs a Clean?

      • Peter AndersonPeter Anderson commented  ·   ·  Flag as inappropriate

        When you say 'in the near future' how near are we talking?

        We want to run a clean each morning for a given build definition (the definitions normal behavior is Gated without clean). If there is a nice way of doing this now that would be great :)

      ← Previous 1

      Feedback and Knowledge Base