Before starting with how to achieve continuous integration with TFS, lets try and understand why it is required?
In software engineering, continuous integration (CI) implements continuous processes of applying quality control — small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.
Which is very true!
And the principles of continuous integration are :
- Maintain a code repository
- Automate the build
- Make the build self-testing
- Everyone commits to the baseline every day
- Every commit (to baseline) should be built
- Keep the build fast
- Test in a clone of the production environment
- Make it easy to get the latest deliverables
- Everyone can see the results of the latest build
- Automate deployment
If you can think for a while how every stuff adds value and helps in getting the quality product out at a higher rate by reducing risk you have already 50% through with the process. Rest all is matter of utilizing the feature provided by the CI tools/infrastructure.
Lemme start with maintaining code repository. If you follow few guidelines, it makes the life much easier to maintain the code. It all depends on nature of the application & process you follow.
Define your environments:
Defining branching is major decision to be taken and it all depends on the scenario or the process you are in. Go throw this site before strategizing the branchinghttp://branchingguidance.codeplex.com/.
For instance, lets consider a simple branching strategy around environments (dev,qa & prod) with single release.
Define environment dependant configuration:
First and foremost, define the configurations for each environment. Configurations as such, DB to point, service url to refer, user accouts to be used etc. This can be achived by having a configuration file each environment.
1. Select the solution
2. Right cick -> configuration manager
3. Define the configuration for all environments (and debug/release modes for local settings & dev workarounds) -> Using Configuration Manager
4. Make use of the interesting feature Add Config Transforms offerred by VS2010/.net4.0 web application project template to maintain web.config for each configurations.
5. Strangly we don’t have this luxury for other application templates. Thr is a combursome procedure of modifying your cs proj file to achive this feature (refer:http://philbolduc.blogspot.com/2010/03/using-config-transforms-outside-web.html).
I prefer to write a small batch scripts which overrides the app.config befroe the build. Call the batch script on pre-build event of the project.
Define TFS build for each environment:
TFS2010 has very strong and extensible support for build J. Its easy and scallable. You can get a smiple build procedure up, by following the new build wizard
1. Go to team explorer in VS 2010 -> Builds -> New Build Definition
2. Define the build for dev environment.
b. What triggers the build. Notice the interesting scheduling options J
c. For which solution?
Path of the soultion to build. You can have multiple solutions build on same time. Have an eye on Build Agent Folder path.
d. Need to drop the output of the build to a location? Oh yeah, you can do it in build defaults.
e. Here comes the most important step of build definition, the Process.
f. Quick tips:
i. As I stated earlier, we will be having a different builds for each environment. Now it’s the time for chosingthe configuuration we defined. Provide appropriate configuration name for the property Configuration to Build.
ii. Want to run the unit testcases? Provide the assemblies for the propert “Test Assembly Filesspec”.
iii. Want to fail the entire build on test fail even if the compliation was successful ? set “Fail Build On Test Failure” to true
iv. Want to run the code coverage? Enable code coverage (refer): http://blogs.msdn.com/b/ukvsts/archive/2009/11/06/enabling-code-coverage-in-vs-2010-beta-2.aspx) and provide the local.testsettigns file to “TestSettingsFile”.
v. Want to run the Code Analysis on the build? Set the “Perform Code Analysis” option. Make sure, you have selected appropriate rulesets in the project (refer:http://visualstudiomagazine.com/articles/2010/03/25/working-with-static-code-analysis.aspx).
vi. Want to deploy the application? (Only Web Apps) Provide publish parameters to “MSBuild Arguments”
/p:DeployIisAppPath=”Default Web Site/WebApplication1″
vii. How to deploy web or any other applications? This is a generic process, invbolves writign some batch scripts J
g. You define the rention policy too.
This ends defining the build for a specific environment. Repeate the above steps for other 2 environments/branches with environment specific details such as ,
1. Solution location
3. Drop location
4. Configuration to run
5. Enablingor disabling of Automatic deployment, Runnign unit test, code coverage or any other details.
Once we have have all the 3 build definitions defined, we can view, enquue,delete or modify the build.
Click onView Builds to see all possible builds
Click Open to explore different features provided and majorly to see what happened with the build.
Opt for alerts to be on track with build status by selecting Project alert option under “Team” menu in toolbar.