This is a lunch presentation on using Team Foundation Server as a build server. Notes for the presentation are below.
This presentation is probably out of date.
The presentation is built with Reveal.js and hosted on GitHub Pages: http://paulzerkel.github.io/pres-tfs-builds/
Edit the root index.html file to change the presentation. All of the files for Reveal.js are in /reveal. The master branch contains the live site.
Check out these presentation notes!
- Microsoft’s Application Lifecycle Management solution
- Includes task tracking, source control, bug tracking, build server, deployments, lab management, etc
- A service often running on a dedicated machine
- Handles running build scripts based on an event
- Often keeps track of build artifacts, retrieves dependencies, logs results, keeps statistics
- Team Foundation Server
- Jenkins
- Hudson
- Team City
- CruiseControl.net
- Many more
- Centralized
- Always building from one place and avoids building off a person’s machine.. Same process every time. Always pulling files out of source control (no “oops! that made it into prod without being checked in)
- Repeatable
- The process is scripted and can be kicked off with one click. No chance of missing a step in a run. Can be run often without taking up anyone’s time.
- Code Health Monitoring
- Integrate more tools in other than just the compiler. Sonar, tests, style cop.
- Continuous Integration
- Build after every commit to make sure all developer’s changes compile together. Constantly getting feedback on the code health monitoring.
- Requires time to set up early on in the project.
- Another piece of infrastructure to maintain.
- Once you get used to automated builds, doing it by hand is a real pain.
Used for automated builds for code stored within Team Foundation System.
Components include:
- Team Foundation Server
- Application Tier. The general TFS install is the entry point for recieving build requests.
- Build Server
- TFBuild service. Handles builds for a team project collection in TFS by acting as a controller, agent, or both.
- Build Controller
- Performs lightweight tasks such as logging information about the build and distributing CPU intensive tasks to build agents.
- Build Agent
- Dedicated to a single build controller. Processor and storage intensive. Can be tagged based on capabilities, IIS, x86, x64, etc.
NA
- TFS 2010 moved from a MSBuild based build process to a Windows Workflow based build process.
- Workflows can call out to MSBuild scripts
- The workflows are called Build Process Templates
- Stored in source control in TFS 2012
- Added into a new TFS project automatically
- Good to organize in one place and include or branch into your project
- Edit them like a normal workflow
- Custom activities can be included
- TFS Extensions on codeplex has a lot of great ones (also supported by hosted build)
- Workflows have arguments that can be customized through the build UI as part of the build definition
A specific instance of a build which requires:
- Name
- Status
- Determines if the build will honor build requests
- Trigger
- Determines how the build is started. Manual, CI, rolling, gated, scheduled
- Source Settings
- Sets what folders in source control are participating in the build
- Build Defaults
- Default settings that can be changed when queuing a build such as the controller and output location.
- The output location can also be turned off if you won't need the resulting files.
- Process
- Lets you pick the process template and customize the arguments
- Pick the sln to build
- Pick the platform and configuration (IMPORTANT)
- Run unit tests?
- Perform code analysis?
- Publish symbols
- Retention Policy
- Set how long build artifacts are kept around
- Can be set based on build result
- You can set what should be deleted after the retention policy is triggered
- Unit testing
- Can match assemblies based on wildcards
- Built in it will execute MSTests
- Adaptors allow 3rd party frameworks like NUnit
- Results of tests included with build
- Code Analysis
- Code analysis uses the FxCop engine. Very similar in nature
- FxCop can be used via an extention
- Deployments
- Can add MSBuild flags to the compilation step to publish a web app to a location
- Labeling
- The workspace can be labeled on a build
- Subsequent builds can target a specific label
Assemblies must be checked into source control and the build controller must point to the custom assembly directory.
- Build your own
- Build your own workflow activities to customize the process
- Open Source (TFS Extensions)
- FxCop
- ClickOnce
- FTP
- Hyper-V
- Lab Management
- Zip
- etc
TFS Extensions has a TFSVersion to help set the assemblyinfo.cs versions when building a project.
- Need to download and customize the workflow to do that
- Can set how the version number is constructed
- Lots of customization available
- Confusing and a little error prone
TFS Extensions has a StyleCop activity that will run stylecop on the source files and report back as part of the build process.
- Helps enforce consistent code style throughout the project
- Can be customized per project
- We haven’t but need to. Ignore headers, ignore unit tests, etc
- Violations can be set as errors
- This would fail the build which seems a bit drastic
- We treat them as warnings
The organization of your project within TFS is imporant. The root of a project should be broken up into areas that target different stages of the software lifecycle.
- Development
- Individual branches for features or releases under development
- Branched from Main
- Give it a name with meaning to the work occuring in it
- Main
- Integration point.
- Branch from here to to Development and Release
- Merge into main to move changes into Release or Development
- Release
- Individual branches for major/minor releases
- Hotfixes can be applied and merged back into Main
- Builds target these branches
A continuous integration build will run any time code is checked in. This gives you quick feedback on the state of the codebase.
- Set up email alerts for builds
- Team Explorer -> Settings -> Project Alerts
- You want to know what is going on
- Create a build definition for the branch you're working in
- Useful to name it CI - Branch
- Pick Continuous Integration or Rolling Builds for the trigger
- Run unit tests, code analysis, and style checker
- Don't copy the output to the drop folder
- You don't care too much for the output
- Turn off labeling
- No need to pollute the labels for the project
A release build will target a branch in the Release folder. Release builds are intended to be deployed to environments outside of the developer's machines such as Development, QA, and Production.
- Create a build definition for the release branch in question
- Each build should use a TFS Version task with the Major and Minor values set
- This will set the assemblyinfo.cs versions appropriately
- Set the build targets appropriately
- Your project should have a solution config for each environment + local
- Probably no need to build the "Debug" or local config
- Make sure the project has configuration transforms as needed
- Especially for web apps, although app.config can be done via Slow Cheetah
- Label the build
- Select a reasonable spot on the network to store build results
- Unit testing, code analysis, and style checking is optional
- It should already be good by the time it gets to a release branch