1 of 14

Continuous Integration With TFS

agile Agile

By Chris Tucker

2 of 14

What we will do and discuss

What we will not do or discuss

  • Discuss continuous integration
  • How to get started with TFS
  • Expand your current experience
  • Go through two examples of
  • All using Agile Templates
  • Install (will give some hints)
  • The crap code I'm using as examples
  • Won't go into depth on the other features of TFS (unless there is time left)

3 of 14

Why Continuous Integration

  • Fail soon and fail often
  • An agile (lowercase a) team MUST have!
    • Swift changes need all the parts to be built and quality checked as soon as possible.
  • An Agile (uppercase A) team MUST have!
    • Not knowing that you have effected quality will grind you to a halt or lose customer trust
  • Automation is crucial to a small teams success
    • If it's not automated, you will waste time every cycle just trying to remember how to put your packages together

4 of 14

Why TFS

  • Fully integrated into the MS development experience
  • Now it's free*
    • Free to team of up to 5
    • A Pro version of Windows or a server for build integration
  • Easy to start using basic features
  • Not too difficult to customize
  • Deep customization possible

5 of 14

Why Not TFS

  • Can't use VS Express products with TFS
  • Not many hosted choices
  • Super cheap if you're going Open Source
    • Assembla (SVN,GIT)
    • CodePlex (TFS,Git Subversion Mercurial)
  • Some of you may still like your current solution (VSS{I kid}, SVN, GIT, TeamCity)

6 of 14

How TFS is agile

  • Agile templates get you using the patterns of agile lifecycle
  • Change to your code can happen rapidly
  • Integrating unit testing into the build process
  • Build soon and build often, test even more
  • TFS can grow with your projects
  • Very flexible, but you can get into trouble.

7 of 14

Definitions

  • Shelf-set: A changeset that is stored at the TFS server under the shelving users account. Anyone on the team can get at it and perform normal operations.
  • Shelve: To push code to a shelf-set. You have options when manually shelving to keep or not to keep the changes in your workspace.
  • UnShelve: to reconcile or merge a shelf-set to a workspace.
  • Reconcile: To apply a change-set or shelf-set to a workspace. Once complete, the changes in the change-set should be applied to the workspace. This usually simply resolves any locks or possible forces some merge activity depending on how different your workspace is from the workspace the shelf was created from.
  • Merge/Branch: Separate but tracked change paths. A tool for continuous maintenance or version management.
    • Support for external tools like WinMerge or 3Diff.
    • Full history with rollback and other tools.

8 of 14

Setting Up Source Control

  • Discuss some strategies and why I chose my standard approach
    • Single Project - Multiple Branches
      • Simple, easy to Manage
    • Multiple Project - Multiple Branches
      • Difficult to manage but may be required by your situation
  • When to branch/merge
    • version completion
    • version start
    • by project or iteration
    • per task

9 of 14

Things they may not tell you

Things to remember

  • Checking in Binary files makes me nervous
    • When you do, you do not have the option to leave your changes in your workspace. This is due to some pre-emptive locking and really sucks. You can get into a lot of toruble if someone cancels your build with exclusinve locks in this way. Unshelving is a pain when you have to clear all the locks my hand or command line.

10 of 14

Simple Builds

  • Defined: Items to build include only .sln files and using a single workspace.
  • When to use them
    • Single or few solution files with ill defined dependencies
      • The reason N-Tier and SOA were created in the first place
    • Multiple solutions with well defined solutions and lots and lots of unit tests
    • Single platform
    • Simple lifecycle
    • Many small projects
    • Complex Branching

11 of 14

Example Time MathWizard-Simple

12 of 14

Complex Builds

  • Defined: Many .sln files or .*proj files, especially .proj files!
  • When to use them
    • Large projects where many solutions are used to break up the builds into manageable chunks, or to fulfil an n-Tier or other multi packaged architecture.
    • Multiple platforms or technologies (.NET, Java, Web, Windows, Mobile)
      • YES YOU CAN BUILD JAVA WITH TFS

13 of 14

Example Time MathWizard-Complex

14 of 14

Resources