VSTS, Visual Studio, VS2010,
prix plavix viagra pour les femmes acheter viagra doctissimo viagra combien ca coute paxil médicament cialis generique en france nolvadex sans ordonnance générique zovirax générique flagyl levitra indien plavix belgique cialis à vendre zovirax comprimés posologie acheter viagra 20mg acheter lioresal baclofen prix levitra pharmacie achat cialis sans ordonnance lasix médicament nolvadex 20mg acheter kamagra gel achat priligy cialis inde acheter cialis internet acheter cialis sans ordonnance viagra temoignage viagra generique en pharmacie plavix 150 mg pilule levitra prix levitra acheter cialis en espagne viagra le vrai acheter accutane cipro xl 1000mg achat cialis en france kamagra belgique cialis 10mg prix commander cialis generique prix priligy priligy dapoxetine strattera 80 mg kamagra oral jelly achat viagra pharmacie cialis 5 mg prix prix aciclovir priligy achat prix cialis 5 viagra pharmacie paris acheter baclofen aciclovir prix clomid sans prescription cialis tunisie acheter cipro kamagra livraison rapide acheter levitra pas chere cialis generique forum prix cialis 10 mg cialis generique 10mg viagra generique belgique kamagra paris achat cialis 5mg flagyl générique acheter clomid acheter zithromax médicaments cipralex viagra generique pharmacie procurer du cialis vente de cialis sur internet pilule cialis cialis luxembourg viagra en pharmacie proscar sans ordonnance plavix prescription plavix 75 mg accutane ligne viagra lyon viagra im internet bestellen strafbar clomid 150 mg achat kamagra oral jelly cialis generique pas cher proscar 5mg cipro 1000mg viagra ou acheter cialis 10 mg generique priligy en belgique accutane sans ordonnance cialis 5mg prix generique zithromax veritable viagra acheter strattera viagra chez la femme cialis bon prix cialis lilly prix kamagra apcalis achat cialis clomid en ligne generique cialis efficace acheter viagra canada viagra naturel pour femme commander cialis en france amoxicillin 500 mg kamagra suisse levitra france achat cialis suisse acheter du viagra achat viagra pas cher acheter acyclovir kamagra en france acheter cialis paypal acheter du kamagra cialis prix strattera 40 mg prix zovirax nolvadex prix clomid 100mg azithromycin 250 mg viagra generique suisse acheter cialis generic viagra effet secondaire cialis ne marche pas médicament baclofen acheter amoxicillin prix du viagra paxil 30mg clomid 50mg acheter sildenafil flagyl ordonnance clomid sans ordonnance forum achat cialis prix flagyl 500 clomid deux comprimés clomid 25mg impuissance sexuelle commander du viagra acheter clomid viagra professionnel acheter du levitra plavix 300 mg prix viagra andorre achete viagra cialis generique france cialis commande cialis 20mg pas cher viagra prix de vente prix sildenafil traitement impuissance cialis generique suisse viagra sans prescription cialis achat forum viagra remboursé par la sécu prix cialis 5mg levitra a vendre

How many Team Build types should I have for one solution?

By Steven Borg • on November 12, 2007

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.)

Related Entries

Recent Entries

Comments

By fuzzelogic on August 11th, 2008 at 12:14 pm

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!!

Trackbacks

Leave a Comment

You must be logged in to post a comment.