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.
I’ve previously blogged about how we practice Continuous Integration with TeamCity at Ninetech but some time has passed and now it is time for an update.
After an upgrade to TFS2010 we started to use its build system for some of our development projects but since many of them lacked automated testing the usage didn’t really take off. To change this, an internship project was started where students from Karlstad’s university would create some way to highlight the opportunity to get immediate feedback for team members as well as stake holders and other interested at our company.
The result of the project can be seen below. It is our TFS TV placed on the wall of our developer room such that all developers, as well as any one who passes by, can see the current status of our projects. It is a WPF app which cycles through all of our TFS build configurations, gathers the latest test data, goes to our web site and fetches the photo of the latest committer, and displays it all on the 42” plasma screen.
The effect we’re after is to raise the level of awareness and usage of continuous integration and automated testing by providing immediate feedback to all teams when something fails and as well as a quick way of keeping track of a project through some of its metrics.
As seen below no one can miss if a build is failing which makes everybody who commits to a project on the screen extra careful not to commit code which is untested or brakes the build in any way.
What’s next? As we’re using a mix of source control systems (TFS, Git, Hg, SVN) and continuous integration platforms (TFS, TeamCity) the plan is to support TeamCity as well and maybe find a way to release it into the wild. We’ll se what happens.
A while ago Manning Publications contacted me through this blog asking for my thoughts on a book that was about to get published. The title of the book was “Continuous Integration in .NET”. Obviously I was honored and this is my review.
I’ve been a Continuous Integration practitioner and evangelist for about a year and it’s been a fun ride. I’ve implemented the practice in my own team as well as helped other teams getting started with the process. I’ve also held a talk at work before 20+ developers about Continuous Integration, written blog posts, and answered questions on Stack overflow.
Are you a .NET developer who finds yourself in projects where releasing software is painful and takes forever? Then Continuous Integration in .NET is the book for you. I’ve been there over and over and thus started researching Continuous Integration tools for .NET about a year ago and found many of which are covered in great detail in the book by Marcin Kawalerowicz and Craig Berntson. The authors are both developers, bloggers, and have vast knowledge and experience with Continuous Integration.
The book is extremely rich when it comes to tools and in under three hundred pages these are some of the tools that are covered; Version control tools like SVN and TFS, unit testing and mocking tools like NUnit and Rhino Mocks, automation tools like NAnt and MSBuild, CI servers like Team City and TFS 2010, UI testing tools, acceptance testing tools, code analysis tools, document generation tools, deployment and delivery tools, and database automation tools. Flavor samples of all the tools you need to automate anything you can think of, and beyond.
In my experience starting with version control, a CI server and Unit testing goes a long way when you’re first starting out on the journey towards Continuous Integration. This is also the message [Kawalerowicz and Berntson] sends throughout the book. However, there are quite a bit of content for experienced CI teams as well, e.g. how to take the process even further with automated deployment, database rollouts or how to deal with speed and scalability issues in your build.
In my mind Continuous Integration is so much more than just the tooling and process automation, it is a complete development practice that dictates some of the team’s behavior. For instance, to get the rapid and repeated feedback that we strive after all team members need to commit working and tested source code at least daily.
I was a bit disappointed that the book didn’t cover any of this aspect. In the early chapters the CI concept is redefined by the authors for the scope of the book to exclude the development practice parts.
Continuous Integration in .NET is a very good and well-worked book and I can recommend it to anyone wanting to get started with CI in .NET but don’t know how, as well as more experienced CI developers looking to extend and fine tune their process.
If you’re interested in the development practice side of CI I recommend you read Martin Fowler’s article as well as the ground breaking book Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall.
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:
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.
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.
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.
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.
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.
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.
Disclaimer: The slides has been cleaned from all customer references in the internal material.