What Our ALM Toolchain Looks Like

 

The first and most important thing for any developer is a version control system, of course. If you don't use one start using one today – seriously. This is an absolute no-brainer for any serious development.

We used to use SourceSafe in the early days (hello, exclusive lock) but soon switched over to Subversion. Main reasons were a healthy ecosystem of 3rd party tools, excellent integration into many other solutions (e.g. via the comprehensive command line interface) and an easy to handle configuration. While we also evaluated TFS, Git and Mercurial, we decided to go with SVN. We don't have distributed teams and no one really works offline for more than a couple of days (which would all be perfect reasons to use Git). At the time of decision, TFS was quite hefty to install and administrate (which has become way easier since then). Basically, this is not a religious question for me, we just decided for the tool that did the job good enough and was easy to setup and handle. We have never regretted the decision, though.

We're using the excellent VisualSVN server, kudos to the guys at VisualSVN Ltd. The server really rocks, it is dead easy to configure and administrate and updates have never been a pain. As clients, we use both TortoiseSVN for shell integration and AnkhSVN for Visual Studio integration.

Next comes an issue tracker – indispensable for a successful team to work. Any issue needs to be tracked with information on repro steps, binaries or test projects, references to other tickets, changesets etc. This is a long-term wedding, as (at least to my knowledge) there is no commonly accepted database schema for issue trackers. Every system uses a proprietary format and if you want to still be able in a couple of years to find out what a certain ticket was all about you better have the same system still up and running or undergo a most of the time painful migration process. After evaluating many different solutions, we decided to go with Redmine. Again, it has a very healthy 3rd party ecosystem with lots of plugins available, is open sourced, so adaptions can be easily made as long as you speak Ruby. It fully integrates with SVN and there is a great reporting solution available for it ;-): Redmine Reports.

The final chain link is the CI Server. We use TeamCity from JetBrains s.r.o. It is a breeze to install and supports both Visual Studio and batch command line compile steps. Most importantly, it allows the integration of our test suite and installer into the build process. I've briefly described the tests in an older blog post.

So this is the first thing everybody checks in the morning:
 

All tests validating, all pending changes easily visible from one central location that can be accessed by anyone on the team, full information on issues, changesets and fixed tickets at one glance in your browser – this is just great stuff.

We're absolutely aware of our responsibility – due to the "snowball" effect of components, any change we make will sooner or later be applied to thousands of applications serving literally millions of end users. Our sophisticated tool chain together with a well-documented QA process helps a great way to release changed DLLs with confidence. The first service pack for LL21 is due next week ;-).