Go and Team Foundation Server

With the release of Go 12.1 our platform for automated build and continuous integration/delivery directly supports Team Foundation Server (TFS) source control as a source of materials. In this post I want to give you a deeper understanding of using this feature. For reference you can find the official documentation about using TFS materials with Go here.

Let’s start with Go’s pipeline model. Here’s the pipeline I use to build the Mingle Extension for Visual Studio. In a nutshell you are looking at the essence of Go here. It would be terribly difficult to model this using Team Foundation build alone. This pipeline is composed of five “stages”: compile, two phases of automated testing, a stage to acknowledge completion of manual testing and finally a stage that packages the installer for the tested product to be published. Note the seamless integration of automated and manual stages of the pipeline. It is quite difficult to do this with Team Foundation Build alone.

Here are two look at the pipeline, one in-flight. The pointers in between the stages indicate whether subsequent stages fire automatically or await manual intervention. In my case I stop the pipeline after the completion of automated testing for a bit of manual testing. When all the manual tests are completed we trigger the resumption of the pipeline through to the end.

Imagine a world where that “publish” stage is polishing off a deployment of your e-commerce app built from Team Foundation source control. You can see how powerful this is.

 

 

This pipeline interacts with TFS in several ways as it proceeds. Let’s dig deeper.

Here is the configuration for pulling build material from TFS:

 

 

The job is configured as a Custom Command that runs a batch file containing:

msbuild /t:Rebuild /p:configuration=%1 /fileLogger /flp:logfile=buildlog.txt /flp1:logfile=builderrors.txt;errorsonly /flp2:logfile=buildwarnings.txt;warningsonly vsc.sln

This build produces a number of “artifacts”: logs, a library of automated tests and the testable executable product that will ultimately be packaged for release.

Stage two, automated API testing, runs MSTest over the test library artifact produced by the compile-build stage. This stage is also configured with a job running a Custom Command that calls a batch file, which contains:

 

 

The final stage, publish, uses TFS’s command line tool, tf.exe, to label the source tree using the value of GO_PIPELINE_LABEL. The value of the environment variable is passed in as a parameter.

We have only scratched the surface.

 

This post is from Mark Richter's blog. Click here to see the original post in full.