We spoke with Chris Patterson, Senior Program Manager Team Foundation Server about the role of automated builds and continuous delivery in modern application development. Team Foundation Service is the Microsoft-hosted version of Team Foundation Server.
InfoQ: Do you think all teams should use automated builds? If so, why? If not, under what circumstances is it important?
Chris: The short answer is yes, they should. First, I like to make a distinction between compilation of code and building. In my view, a build must include your unit tests at a minimum, if they don’t then you are simply compiling. Where this mantra really comes into play is for projects that don’t actually compile. With the rise of HTML5 and JavaScript for even native Windows applications you no longer have the compilation step to give you that first level of feedback so your unit tests are now your first line of defense between you and the bugs you introduce. I would even recommend a team of one set up an automated build system.
With this in mind there are a number of good reasons to have an automated build.
The first benefit is really just a side effect of the process. An automated build forces the developer or development team to create and maintain a repeatable and documented process for building their software. Most developers have been bitten by the “It worked on my machine” bug at one time or another. Typically this is due to some dependency that is present in the developer’s workstation that is not present in either the test or customer environment. Having a consistent repeatable automated build process can help prevent some of these situations by forcing the team to make sure they can compile their software and run some basic set of unit tests outside of the IDE and off of the developer’s workstation.
In addition automated builds are great for finding and highlighting other common problems:
- A developer checked in a change that breaks the build
- A developer forgot to check in an important file or configuration change
- Your build scripts simply don’t work anymore or your software does not pass the unit tests anymore
There are many good articles about the importance of automated builds in the software engineering process one great example is from Martin Fowler.
InfoQ: Would you say it is necessary to know how to write MSBuild scripts to successfully use automated builds?
Chris: MSBuild is simply one technology for creating an automated build script and it happens to be the one that Visual Studio uses. From that perspective if you are working in Visual Studio you should be familiar with MSBuild and how to write those scripts.
In the .NET community, there are a couple of other popular build scripting tools such as NAnt and PSake. I personally have not had a huge amount of experience with either of these, but I do know people that are very passionate about them.
In Team Build we use a combination of MSBuild and Windows Workflow. MSBuild is used for processing Visual Studio solution and project file and is how we automate the compilation of code. The overall orchestration of getting your code from TFS, executing MSBuild, running unit tests and publishing the results back to TFS is handled by Windows Workflow Foundation. This combination creates a very powerful and flexible system that developers can use to automate everything from builds, to managed test environments and even production deployments.
However, if you are working with other technologies, you would want to understand how to work in that build system.
InfoQ: What kinds of automated deployment (i.e. continuous delivery) scenarios do you think TFS is particularly good or bad at?
Chris: One of the strengths of Team Build is that you can do anything you want and probably the biggest weakness of Team Build is the same. The Windows Workflow runtime is extremely powerful and capable, however, it does present a bit of a learning curve for developers. The ones who have invested in the platform and really know it do some amazing things that we would have never thought to do with our agents. For the developers that don’t yet know WF even the simple build customizations can be challenging. This means that Team Build can be good at any kind of automated deployment, however, it may not be immediately obvious to developers how to accomplish their goals.
In order to improve the developer experience around continuous delivery, we worked with the Azure team to enable a seamless continuous delivery workflow from the Team Foundation Service to Windows Azure. With just a few clicks a developer can connect their Team Foundation Service account to their Azure subscription. This process creates a build definition that is preconfigured to deploy either a web site or cloud service into that subscription. All the developer needs to do is point that build definition at their solution and we will take care of the rest.
Over time we expect to have more of these types of solutions available for customers of the service as well as customers who install TFS inside their firewall.
InfoQ: Some people advocate using continuous delivery not just to QA, but to production itself. That is to say, if the automated tests pass it will be automatically deployed into production with no manual intervention. What is your opinion of this idea?
Chris: I am a huge proponent of the continuous delivery to QA. I think the ability to get working product and changes into the hands of your testers is one of the best things you can do to improve your overall team velocity and the quality of your software. In addition, if you can’t do continuous delivery with your testers there is no way you can do it to production.
Continuous delivery to production is becoming more popular in certain circles. I believe this is prudent with certain types of business and products, but may not be for others. It requires an extreme amount of discipline on the part of the developers and a huge amount of confidence in your automated builds to catch any problems before they are delivered to your customers.
InfoQ: What advantages do you see in using TFS build agents over standalone build servers such as CruiseControl?
Chris: The primary advantage is simply the integration. Team Build is part of TFS and is delivered in the box as well as on the service. This means that you get a solution that is designed to work together and if you have any issues we have world-class support to help you out. Team Build ships with templates that are preconfigured to work with your Visual Studio solutions and the Visual Studio test runner. This allows a developer to get up and running with a build in just a few minutes. In the case of the Team Foundation Service the developer does not even need to install a build agent. We provide build agents as part of the service that are capable of building most projects that you can create with Visual Studio.
Of course the standalone products have an advantage of significant communities working on them. Something like CruiseControl or Jenkins have a wealth of plugins that provide different capabilities. In addition, both of them have agents that will run on Linux and MacOS. In many cases we have customers who use both Team Build and a standalone build server. Team Build is used for everything running on Windows, and the standalone server does any builds that need to run on another platform.
InfoQ: Are there any plans for offering Java, iOS, and/or Android build agents?
Chris: In the increasing heterogeneous world of software development we are continually improving our capabilities when working with other platforms.
We provide a set of workflow activities and MSBuild tasks that will enable you to automate builds using Ant and Maven, which are both popular in the Java community. In fact we use these activities internally to build our Team Explorer Everywhere product, which is written in Java. Because the Android development environment is also based on Eclipse and Java, we can use the same techniques.
At the moment iOS applications can only be built on a Mac and we don’t have an agent that will run there yet.
About the Author
Chris Patterson is a Senior Program Manager working on Team Foundation Server. He has been working in the software industry for 15 years, working with a variety of technologies ranging from Classic ASP and VB to Java and .NET. Prior to coming to Microsoft in 2005, he worked for TogetherSoft and Borland where he helped customers improve their software development processes through mentoring and training. At Microsoft he worked on the load, web and manual testing features in Visual Studio 2008 and 2010. Currently he is responsible for the build automation components in Team Foundation Server and the Team Foundation Service. He enjoys helping customers solve problems, reading and learning about technology, and spending time with his family. You can find him on Twitter as @chrisrpatterson and in the product forums.
