Orcas Team Build Continuous Integration spec is now available


Back in early December, I wrote the post, More on the Orcas features for Team Build, that described many of the new features that we are adding for Orcas, elaborating on what Brian Harry had written in his TFS Roadmap post.  I’m very happy to say that later in December, we finished the implementation of those features, and they’ll be in the next CTP.

A few days ago, we published the specification for Continuous Integration and the other features that we have added to Team Build.  It’s available in Team Foundation Server section of the Feature Specifications for Visual Studio and .NET Framework “Orcas” page.  Here’s the direct link: Continuous Integration.

Before you think, “Wow, a spec, how dull,” take a look at it.  It’s fewer than 20 pages of Visio wireframes of the GUI.  There’s no dense text to wade through.  Please check it out and post your comments, either here or on that site.  Unfortunately, the TFS Specification Feedback link takes you to a page where the two choices for feedback are Get Latest on Checkout and Annotate.  Hopefully, that’ll be fixed next week.

tags: , , , ,

Comments (14)

  1. dls says:

    XPS hurdle navigated! My first impression is that the UI is clean, everything up to page 14 (i.e. the build definition wizard) was fairly intuitive. I think I lack some context to appreciate the build explorer and queued build management UI in the later sections, but that doesn’t worry me.

    I am interested in the details of the build triggering feature, and I’m curious to know if there’s more information available. Mostly, I want to answer questions along the lines of "Exactly which checkins where will trigger a build?" In that context, I’m also interested to know if there will be a way to exclude paths as triggers for a build. On the other side of the question, are there other actions besides checkin that can be made to trigger a build (e.g. label application)

  2. buckh says:

    The way builds are triggered is that when a checkin occurs Team Build looks at all of the build definitions’ workspace mappings (Workspace tab) to determine which build definitions have mapped the files that were modified.  Any build definition that has mapped a file that was changed is queued to be built.  Team Build is able to do that quickly and efficiently on the data tier.

    To exclude something from triggering a build, you would need to either not map it or cloak it in the build definition’s workspace mappings.

    Nothing other than a checkin will automatically trigger a build.  You could, if you want, build something that listens for any kind of event and then, using the Team Build OM, queues a build.

    Thanks for the feedback and the questions.

    Buck

  3. Tim Hibbard on TFS Solutions – Access to the path BuildLog.txt is denied and TF42004. Brian Harry…

  4. Lets Give Feedback: Orcas Team Build Continuous Integration spec is now available

  5. The specs for the new Team Build Continuous Integration module that is going to be included in Orcas

  6. Brent Schooley says:

    Appears to me that you guys still don’t get that the usability of this thing on large projects is horrible.  On the target selection you offer absolutely no way to sort the solution files and changing the order requires clicking the up and down arrows like mad!  I would suggest a dual listbox (source list and target to be built list) that allows you to add things from the list on the left to the list on the right.  Also, couldn’t hurt to allow dragging to reorder.  By default, when I add a solution to the build list it should occupy the next available build target.  I should not have to reorder the items every single time I add a target.  If you’re willing to lay out the GUI in a 14 page doc like this, I hope you are willing to listen to this feedback.  I find the current Build Customization to be a pain and it appears this new version won’t even address those issues.

  7. buckh says:

    You’re right that we didn’t do anything about it in the Orcas release.  We simply didn’t have the time to address it.  The good news is that we do plan to address it after Orcas and replace that part of the UI (the last vestiges of the old wizard).  I’ll record your comments so that we take your feedback into account when designing the replacement.

    Thanks,

    Buck

  8. Brent Schooley says:

    Thank you for your prompt response Buck.  Sorry if I came off a bit harsh but I had just been using the VS 2005 Team Build UI when I came across this spec and got a little excited that maybe it would be better.  I currently find myself checking off the top solution in our source control and then dropping down into the XML.  I did find a program called MSBuild Sidekick that is somewhat helpful but doesn’t integrate as nicely with TFS as I would like.  Our main build has approximately 90 solutions in it (it’s not organized as nicely as it should be) so the build customization UI is almost impossible to use.  I look forward to seeing whatever improvements the team is able to provide

    Thanks,

    Brent

  9. buckh says:

    No problem.  We absolutely agree that it needs to be improved, and ordering 90 solutions in the current UI is clearly painful.  I’m hoping we can make you smile in the future.

    Buck

  10. Buck Hodges says:

    When we posted the Orcas Team Build Continuous Integration Spec , you may have noticed that there was

  11. Buck Hodges says:

    Here’s the announcement. Please download the TFS Virtual PC image and let us know what you think. Except

  12. Buck Hodges says:

    Last fall, Clark Sell wrote a blog post called Stop, the build is broken!! that introduced a checkin

  13. Buck Hodges says:

    As you probably already know, Orcas Beta 1 has shipped. Internally, the product team is focused on finding

  14. Buck Hodges says:

    The WorkspaceMapping.xml file is one of the files generated when creating a new build type. Those of