Orcas Beta 1 has shipped – summary of Team Build beta 1 features and links

As you probably already know, Orcas Beta 1 has shipped.  Internally, the product team is focused on finding and fixing bugs for beta 2 (and has been for nearly a month now).

The release includes a Virtual PC image with all of Visual Studio Team System plus Team Foundation Server, which you can download now.  There’s also an image that has only VSTS on it, but that’s not nearly so interesting, right?  ;-)

Be sure to read all of the instructions on the download page.  The release is in the form of a base image, which was also used for the March CTP, and a differencing disk image with the Orcas release on it.  If you’ve already gotten the base image from the CTP, you don’t have to download it again.

From Brian’s updated roadmap, here’s the high-level list of features in Orcas Team Build beta 1.  Items marked as “new” were not in the March Orcas CTP.  I’ve added links to blog posts for each of the features.

Build (interview/demo, screencasts)

  • Support multi-threaded builds with the new MSBuild.
  • Continuous Integration – There are many components to this, including build queuing and queue management, drop management (so that users can set policies for when builds should be automatically deleted), and build triggers that allows configuration of exactly how when CI builds should be triggered, for example – every checkin, rolling build (completion of one build starts the next), etc.
  • Improved ability to specify what source, versions of source, and other build properties (BuildStep task, GetBuildProperties and SetBuildProperties tasks).
  • Improved extensibility of the build targets – such as ability to easily execute targets before and after each solution/project is built.
  • Improved ability to manage multiple build machines (see extensibility, screencast).
  • Stop and delete builds from within VS.
  • .NET Object model for programming against the build server (another example; using it via PowerShell: here, here, and here).
  • Simplified ability to specify what tests get run as part of a build (TestContainer support is in Orcas).
  • The ability to store build definitions anywhere in the version control hierarchy (see extensibility).
  • Scheduled builds (new) – You can schedule builds to happen at specified times.
  • Improved build agent communication (new) – We replaced .NET binary remoting with WCF web services, simplifying some configuration and security aspects.
  • Ability to run GUI tests as part of a build (new) – Automated builds used to run tests in such a way as to prevent access to a GUI desktop.
  • New checkin policy for broken CI builds (new) – Preventing checkin while the CI build is broken.

We’ve made a very large number of improvements to the build process in the form of overridable targets, properties, and new tasks.  We made a substantial effort to address many of the issues that have come up in the MSDN build automation forum where things were either not possible in v1 or required hacks.  We hope that our efforts in Orcas will show that we are listening and responding.

In beta 2, there is support for client certificates (X.509) and HTTPS communication from the application tier to the build agent.  The result of our work there is that it’s much easier to have a build agent exposed to the internet.  Our extranet support in build is still not as good as it should be, so there will likely be more work in this area in Rosario.  The changes in Orcas beta 2 are a big improvement, though.

There are a few areas without links, and I plan to update this post with those links as I write about them.

Comments (8)

  1. davidacoder says:

    Have you thought about how to access build results via http for an extranet scenario?

  2. buckh says:

    Yes.  It deserves a post on its own, but here’s the basic approach.  The drop location would need to be exposed through ftp or http server.  There’s nothing in the box for that, so that would need to be done manually.

    The build log location can now be an URL.  So, when you bring up the build report in VS, you can click on the build log URL, which can reference the build log via the ftp/http front end mentioned earlier.

    Putting it all together, I believe the following would be a solution using Orcas.  This would allow the builds to be available both locally and across the internet, with the AT on either being on the internet or local.

    1.    The drop location is a UNC path accessible by the build agent (i.e., it’s on the same network).

    2.    Set up an FTP server to provide secure internet access to the drop location (other options include web server, web services, etc., but FTP seems simplest).

    3.    Open up the necessary firewall ports to allow the AT to call the build agent and vice versa.

    4.    Use the Orcas SetBuildProperties task to set the build log location to be an URL (ftp or http/s) at the end of the build so that VS users can click on the link in the build report and see the build log over the internet.

    Note also that there will still be a limitation where test results cannot be published if the AT does not have access to the UNC drop location.  That is because the Whidbey and Orcas Test SKU code implements test publishing by having the AT read the test results file directly off the UNC share (it’s not uploaded like version control files).  I have been told they are considering changing that for Rosario.


  3. davidacoder says:

    Cool! Having access to the build log goes a long way to improve the situation.

    I haven’t looked at SetBuildProperties, but if I set the location to an https once the build is finished, would users from within VS be directed to that location even when they click on the drop location or tests in the build report? If that was the case, the situation would be 100% perfect, I don’t actually mind setting up the necessary web server stuff by myself. But maybe a post of its own would indeed be best for that.

    Thanks a lot for taking this so serious :)

  4. buckh says:

    VS would display the build log by using the https URL, but the drop location itself will still be a UNC path.  That had larger ramifications, so we couldn’t do that at this stage in Orcas (it would end up being a feature rather than a bug fix).

    There’s no good answer for the test results, since the AT reads the test results file straight from the UNC path.

    We hope that even though there are these limitations that we’ve made sufficient improvements to make it usable in Orcas, whereas v1 really didn’t support enough of it for there to be any practical use.


  5. Ben Ryan on An override for "Get Latest on Checkout". Buck Hodges on Orcas Beta 1 has shipped – summary…

  6. Buck Hodges says:

    Visual Studio 2008 Beta 2, including Team Foundation Server 2008, is now available for download . As

  7. Visual Studio 2008 Beta 2, including Team Foundation Server 2008, is now available for download . As

  8. Visual Studio 2008 Beta 2, including Team Foundation Server 2008, is now available for download . As