Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily - leading to multiple integrations per day. - Martin Fowler 

Martin Fowler’s article “Continuous Integration” listed several key practices that make up “Effective CI”. Here is a quick overview of how Team Foundation Server combined with Automaton can help implement some of these practices.

Key Practices identified by Fowler:

1. Maintain a Single Source Repository

2. Automate the Build

3. Everyone Commits Every Day

4.  Automate Deployment

Side Note:

Best Practices for setting up projects in Team Foundation Server

Taken from TFS Best Practices Guide

- Decide on team project structure
- Understand the culture and requirements for each of the teams
- Map requirements to our logical and physical guidance and create first draft of the logical
- Make necessary modifications to the structure (baseless merge where appropriate)
- Finalize logical and physical diagrams
- Follow release scenarios on these diagrams
- Create Team Project and physical version control structure (import any existing code)
- Create best practices and provide training
- Learn from experiences, customize the branch structure, and make it yours

1: Maintain a Single Source Repository

Team Foundation Server’s source control service provide branching and merging capabilities that help to ensure a centralized and controlled repository for all items needed to build the application successfully. Figure 2 details the specific folder structure and branching strategy used at a former company.

Figure 2 Source Control Structure

2: Automate the Build

A build process helps ensures that the code will compile independently from the developer’s workspace and standardizes configuration across the promotion process. Oftentimes developers will forget to check in critical files and then deploy from their computer. After the initial release everything may run fine but when the next developer checks out the source to make modifications they soon discover that the application no longer builds.

• Determine promotion process needed for project (dev, staging, release)
• Create a Build Type on team foundation server for each promotion type
• If .Net is used configure build types for each solution
• If a website is used configure web deployment project for each build type (this is where dev config files and production config files are specified)
• If the application is an access or .asp application then configure .bat files or other script files. These will execute during the build process (this may run testing against code or verify that certain dll’s are registered)

3: Everyone Commits Every Day

Checking in code is done as soon as a new task is completed. If a task is carried over to the next day the item is “shelved”.

Figure 3 Check-In - Build - Deploy

4: Automate Deployment

note: since the time I had documented this we have upgraded to TFS 2008 which has made CI simple and eliminated the need for Automaton. 

At a previous company one of our goals was to have an integration process that allowed us to provide updates to an application as real-time as possible. The deployment process was setup to build and deploy to the appropriate server as soon as a developer checks-in code. This allowed us to push out new features and bug fixes without having to worry about the manual process of copy files and testing to make sure the appropriate references have been set.

• for web projects this involves configuring the web deployment project for the solution to deploy the compiled source to the correct server for each build type
• for non .net solutions like access or asp this may involve creating bat files that are executed by the build server to copy the necessary files to each server

The key to making the deployment “Real-Time” is to either write custom code that hooks into Team Foundations Servers “Check-in” event or use a third party application that does that for you. In our case we use Automaton.

Automaton is configured to run the specified build configuration when code is checked in. You can also monitor the build status or view the history of the builds using their web interface.

Web deployment projects can be a useful addition to your solution as well. Staging and release configurations can be controlled during the automated deployment process (i.e. web.config file that has dev, staging, and production settings).

Figure 4 third party TFS add on

Credits:

Martin Fowler http://www.martinfowler.com/articles/continuousIntegration.html