: Continuous Integration with Team Build “Orcas”

We look forward to hearing what you think about the new Team Build features in Orcas!

Scheduled builds are supported as well, but they didn't exist when this interview occurred.  You can read about scheduled builds at http://blogs.msdn.com/buckh/archive/2007/02/07/you-can-schedule-builds-in-orcas.aspx.

There's also a description of some of the lower-level changes, such as more hooks in the build, at http://blogs.msdn.com/buckh/archive/2006/12/02/more-on-the-orcas-features-for-team-build.aspx.

Finally, you can try it out for yourself in the March Orcas CTP: http://blogs.msdn.com/buckh/archive/2007/02/28/orcas-march-ctp-is-available-now-and-includes-new-team-foundation-server.aspx.  It doesn't have build scheduling either, but it's got everything else you'll see in the interview.

Buck
http://blogs.msdn.com/buckh

Hi, This feature is the way to go !. We are currently experimenting with continuous integration and we recognize that its very import that the build server is "clean" : no dlls in the gac or visual studio installed, etc Otherwise the succes of the build could be tied to a particular setup. Am I making sense and does the Orcas release run the build in some kind of isolated context seperated from the machine it is being build on? Kind Regards, Tom

Looks great... a few questions...

1. It looks like the build agent is actually a dummy/slave machine and it is actually the TFS that monitors checkins and when a build is needed it tells a build agent to run that build. Is this the case? If so, can you have a pool of build agents rather than specifiying a specific agent for a specific build?

2. The build status UI looked like it was passive... in other words you actually had to decide to look at the build status screen to see if one failed or whatever. Is there any type of notifications that just pop-up if a build fails... sort of like cctray? CCtray makes things so easy... you can basically ignore it but a quick glance without opening any UI dialog and you can tell the status via the Green-Yellow-Red indications.

3. Is there any labeling in source control that corresponds to a build? This could perhaps be used because a build is compiled as Debug for testing but then when we decide to release the build we want to actually rebuild from the same source to create a release/install package. Or, is this just part of the build project file itself? (Sorry we have worked with TFS build at all yet.)

4. How easy is it to add additional build steps like perhaps running FxCop or Simian or Fitnesse tests? Can the reports from those third party tools be integrated into the data warehouse?

Thanks.

BOb

 

 

 

buckleyXP,

I'm glad to hear that you like it.

You are right that you generally want the build machine to be as clean as possible, with nothing unnecessary installed on it.  However, if you want to run unit tests or code analysis, you'll have to install VS Team System for Testers, Developers, or the Suite to get those features.  So unfortunately, it's not always possible to avoid installing VS.

Buck

Bob,

Thanks, I'm glad to hear that.

1. Yes, you are correct on the first question.  In Orcas, though, there is no way to specify that it should automatically pick an agent from a pool rather than specifying an agent (either the default for the build definition or picking one in the Queue Build dialog).  It is something we are looking into for the release after Orcas.

2. There isn't an equivalent to CCTray in the box with Orcas, but we are considering creating one as a power tool for Orcas (and then shipping it in the box in the release after Orcas).

3. Yes, the sources in the workspace used by the build are labeled as part of the build process.

4. Adding additional steps is straightforward.  For FXCop, there's either the ability to run the product version in VSTS for Developers, which is called code analysis, that requires VSTS for Developers to be installed on the build machine.  For the others, you may be able to find custom msbuild tasks that others have built, or you may build one yourself.  The easiest thing to do is to use the Exec task that's built into msbuild, but then you want get any reporting from that.

Integrating the information into the warehouse should simply require that you write a custom task that runs the tool as part of the build and calls the necessary build APIs to report the results.

Buck

Are there any changes to team build that might help deal with the current hell of dependant solutions in different team projects?

It's interesting to me that Continuous Integration wasn't originally built into this product.  I believe Microsoft is going to have an uphill battle winning over those of us who have gone through great pains to integrate and implement CI with CruiseControl.Net, Subversion, Nunit, NCover, et al.

While these third party/open source tools are not likely to provide the rich integration with Visual Studio that TFS can provide, I've now got so much invested in these tools that it would be fairly low ROI to look at a Team Server implementation.

Are there any real must-haves in implementing a Team Foundation Server approach into my Source Control/Build process that aren't immediately obvious on the home page of the product (keeping in mind the use of Subversion as a source control solution)?

PerfectPhase, Orcas Team Build allows you to map code from other team projects, whereas it required a hack to work around the mapping limitations in v1.

Is that what you are after?

Buck

Leadfoot, that's a difficult question to answer correctly.  The fundamental question of value is directly tied to your statement about the integration.  If the rich integration of work item tracking, source control, build automation, test automation, reporting, Visual Studio, and Office helps you get more stuff done in less time, then Orcas is worth the time effort.  However, if you compare the individual features in isolation there's not so much motivation.  We are really focused more on excelling as an integrated product and getting deeper in each of the feature areas over time (as compared to going deep in the areas and then trying to glue them together later).

I hope that helps.

Buck

1. When providing optional "MSBuild command-line arguements" do these get passed as parameters to the TFSBuild project or just to the targets which use msbuild (ex. CoreCompile)? It would be nice if I could use them at the TFSBuild.proj level for enabling/disabling custom build steps.

2. Is it possible to create custom build triggers?

3. Does the build agent manager show a build report of previous builds for that the agent?

4. I see that builds can be locked for retention through the build mananger. Is this available through an API?

Cedric,

1. The command line arguments are actually passed to msbuild.exe as part of a dynamically-generated msbuild.rsp file.  So, if you specify /p:SomeProperty=SomeValue, the property is global and would be available in all of the projects.

2. I'm not quite sure that I understand the question.  You can add customization via the tfsbuild.proj file.  You can register a web service to get notification via a BuildCompletionEvent (use bissubscribe to register).

3.  We don't show that in the GUI.  We didn't feel that there was a lot of value in viewing the build agents used to run builds, so we didn't add a column for it in the display.  That information is stored in the database, if I remember correctly, so you could write something using the build client API that would show you that.

4. Yes.  There's a new build client API in Orcas.  The VS GUI was written on top of that API, and it's a public API.

Buck