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:
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 ;-).
2 Comments on “What Our ALM Toolchain Looks Like”
thanks for your overview. Every time it’s good to look how other Development/ALM environments and tool chains are build.
Good to know it is of value to you, thanks for the feedback :). Enjoy your weekend.