Share →
Buffer

How many Team Build scripts should you create? Basically, you should create one build script for each and every way you’d like to report on your data. For instance, you should have a build script for your Continuous Integration (CI) build, one for your daily build, one for a weekly build, and one for an on demand build. You may even want a separate one to run only when you actually release to production.

Here’s why you really want so many build scripts. The Visual Studio Team System (VSTS) and Team Foundation Server (TFS) system tracks build information according to build name and build run. Thus, if you execute a build called “My CI Build” twice, Team Build will record data about each build, and will categorize the build information according to the build name. The Team Build report gives you data about each build, and, most importantly, the difference between this build and the last successful build of the same name. This means, that in the “My CI Build” example, the second build report would show the difference between it and the first build. Bottom line: you can tell exactly what check-ins occurred and what work items were worked on BETWEEN the first and the second “My CI Build” build. (This is true even if there were other builds run by the server, as long as they have different names.) Thus, I can see, at a glance, EXACTLY what transpired between the two builds. And if the build is broken, I can find the offending code extremely rapidly! I can also report to anyone who needs the data, exactly what was accomplished!

So, here are a few recommendations around the builds scripts you’ll need:

  • Continuous Integration (CI) build script – This script runs every time someone checks in code (with certain restrictions). Since you likely won’t want an aggregate report on these builds, you can actually modify the build to not archive the build status in the TFS Warehouse.
  • Daily / Nightly build script – This build runs every night at a set time. This build shows you what was accomplished during that entire day, including quality metrics, code churn, etc. This is one of the most valuable builds, since its reporting is clearly segmented by time — one build per day. This allows a team to see what is being accomplished on a day to day basis. Very useful for reporting quality changes inside of an iteration.
  • Weekly build script – This build runs every weekend. Like the daily build, it will allow the reporting engine to show you what was accomplished that week, and how quality changes from week to week. This allows you to see aggregate changes over a chunkier time sequence, namely weeks. Very useful for reporting quality changes over several iterations, according to time.
  • End-of-iteration build script – This build runs at the end of every iteration. This gives you metrics on what was accomplished during the entire iteration.
  • Release to production build script – This build is run after the code has been released to production. Note that you do NOT run this build to CREATE the executables for deployment, but run this simply to generate the metrics around what work was accomplished during this release. (Note: always release the executables that have gone through the testing process to production. Do not recompile the ‘same’ code and push directly to production. It’s too dangerous.)
  • On-demand build script – This one is used for folks who just need to trigger a build whenever. Unless it’s necessary or useful, you may choose to have this build not report anything back to the data warehouse.

So, how do you create all of these builds? It sounds like lots of work, but it’s not. Because these builds are being used primarily for reporting, they are all going to be nearly identical. (You may choose to have some of them not report their data to the warehouse, but that’s about it!) So, all you do is create the first build (the hard part), and copy it several times, giving it a different name each time. That’s all there is to it! (If you feel you’ll be making changes to the build, you may also want to consider branching the TFSBuild.proj file directly in place. This allows you to merge changes between your builds.)

Print Friendly
Tagged with →  
  • Pingback: Team System News : VSTS Links - 11/14/2007()

  • fuzzelogic

    Hi!
    so lets say I have a team solution called Main. then under that I have a solution called MyApp. but ALSO under MAIN I have another solution called UnrelatedApp. when I run the Build script for UnrelatedApp with Team solution set to MAIN, it ‘brings in’ the associated work items for MyApp. Will those be lost, or will they still be there when I run the build script for MyApp. Hope this makes sense!!