Rickard Nilsson

  • Blog
  • Archive
  • About
  • Contact

Welcome to rickardnilsson.net

Rickard Nilsson is a software architect, developer, craftsman, agile enthusiast, and father of three... More

Rickard blogs about crafting software using .NET tooling and solid, development practices.

Follow @rickardn

Top Posts

  • Applying stylesheets dynamically with jQuery
  • My customized Son of Obsidian Visual Studio color scheme for ReSharper
  • .NET Development with Visual Studio on MacBook Pro
  • Code Kata Cast
  • ReSharper User tip #2: Refactor rename namespace
  • Combining and minifying JavaScript and CSS files with Ajax Minifier
  • Dependency injection in ASP.NET MVC with Unity IoC Container
  • C# REPL and Interactive interpreter

Categories

  • .NET
  • Agile
  • ASP.NET 2.0
  • ASP.NET 3.5
  • ASP.NET 4
  • ASP.NET MVC
  • BlogEngine.NET
  • C# 2.0
  • C# 3.0
  • C# 4.0
  • Continuous Integration
  • CSS
  • Design by Contract
  • Design Patterns
  • iPhone
  • JavaScript
  • Kata
  • Moles
  • Open source
  • Personal
  • Review
  • Social media
  • Software development
  • TDD
  • Testing
  • Umbraco
  • Unit testing
  • Unity
  • User tip
  • Web development

Five most recent posts

  • How to unit test your database code when using ServiceStack OrmLite
  • Extract class - ReSharper Ninja tricks
  • ASP.NET MVC 3 Template with built in JavaScript and CSS merging and minification
  • ReSharper Ninja tricks - Generate code from usage
  • Unit testing continuously

Tag cloud

  • agile
  • blogengine.net
  • c#
  • code kata
  • codegarden11
  • continuous integration
  • css
  • dependency injection
  • fakes
  • iso 8601
  • javascript
  • jquery
  • refactoring
  • resharper
  • resharper usertip
  • tdd
  • testing
  • umbraco
  • unit test
  • unit testing
  • visual studio

Recent comments

How we practice Continuous Integration with Team City and ASP.NET 4

Sunday, 12 September 2010 23:57 by Rickard Nilsson

In my current project we have adopted the Continuous Integration process and its key practices, some of which we’ve used in previous projects, but not all at once.

The project technology stack looks like this:

  • ASP.NET 4 (MVC)
  • Team Foundation Server 2008
  • Team City Professional
  • IIS 7
  • IIS Web Deploy

Single Source Repository

We have been using Team Foundation Server since version 2005 and all new and ongoing projects use it, however, Continuous Integration takes source control to another level and require us to put more stuff in there than we are use to. For example, all versions of web.config is stored and version controlled through the Web.config Transformations in ASP.NET 4. This gives us easy access and great control over the different configuration setups we use in all our environments.

Automated build

Compiling, building and running unit tests is something we’ve been doing for years in Visual Studio, but when we had to do the same in an automated Continuous Integration process we could not rely on the build scripts generated by Visual Studio (e.g. all .csproj-files) alone but had to learn MSBuild our selves. It turned out to be a very good thing. Build scripting languages like MSBuild give you the power to do pretty much anything you need to build your software in an automated fashion, and it is the core building block for Continuous Integration and development automation in general.

We have for instance used MSBuild scripts to automate deployment to multiple sites and to generate code coverage reports publishable in Team City.

The build is self testing

In my opinion, to be able to automatically verify that features we implemented earlier continue to work throughout the project and beyond, is the single most valuable practice in our profession. Think of how many hours you spend testing the same thing over and over, if you don’t have tests. Start automating testing today, and you do not want to go back.

The automated testing part of Continuous Integration is what really makes it all worth it. Plus, the rapid integration feedback act as a motivator for keeping the test coverage high and not falling for the temptation to get lazy and skip tests. If the coverage drops you can not be as confident that the code is healthy even though the build passed.

My highest priority is unit tests, followed by integration tests. I’ve started to look at acceptance testing and I plan to integrate that in our CI process later.

Everyone commits every day

A short check in-cycle is key to getting value from Continuous Integration. In practice this means that I try to check in as soon as I can describe the change as a check in comment. If I have a hard time describing the change, it’s probably a sign I have done too much, and should have checked in earlier.

An integration machine builds on every commit

We chose to use Team City on our build servers because it was so easy to get started. In my first attempt I installed Team City on my dev machine, created a new project in the web user interface, connected the project to TFS, and hooked it up to build using the Visual Studio .sln-file. It took less than 20 min to get a full Continuous Integration build running on every check in. But it doesn’t stop there, Team City supports every imaginable tool for build automation and is fully extensible.

Automated deployment

In previous projects I’ve always felt impeded by a slow and error prone deployment process. A consequence is often that deployment can only be performed by one individual from his or her machine. In my current project I focused hard on getting it automated from the beginning. We have multiple sites that all need to get deployed at once so we’ve set up a build configuration in Team City where anyone on the project at any time can at the click of a button, get the latest from source control, run the check in-tests, and deploy to all servers. Usually this takes no more than a minute.

The secret behind this is the new IIS Web Deployment Tool from Microsoft (also known as MS Deploy). It enables a user without administrator privileges to synchronize the content of a site in IIS. Synchronization is key to making the deployment go super fast since we never need to do a full transfer, only the changes are pushed.

Tags:   continuous integration, agile, continuous deployment, test coverage, testing, unit testing
Categories:   ASP.NET 4 | Continuous Integration | Testing | Unit testing
Actions:   | Ping backs (1)

Slides from my talk on Continuous Integration

Saturday, 11 September 2010 12:33 by Rickard Nilsson
Slides (in Swedish) from my talk on Continuous Integration held internally at Ninetech September 9th.
Continuous integration
View more presentations from rickardnil.

Disclaimer: The slides has been cleaned from all customer references in the internal material.

Tags:   slides, ci, continuous integration, unit testing, agile, testing, continuous deployment
Categories:   Continuous Integration | Unit testing
Actions:  
 
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.
© 2008-2011 rickardnilsson.net
Creative Commons-licens