A Quantum Immortal

After having used it for a few weeks, I have this to say following my last post:

1. Great Support! We’ve had a couple of issues with Teamcity, some because our owns unit tests "maliciously" killed all java processes as a form of cleanup, and this killed the TeamCity Build Agents, and some other problems related to which version of the JVM was to be used. The TeamCity support staff and developers were extremely helpful and responsive, and aided us to get a stable Continuous Integration system up and running.
2. Enjoyable UI – the AJAX UI is usually very responsive, and rather feature-complete. It gives easy access to builds, projects, a sane way to manage settings and source control bindings, and a quick way to access the full log for every individual build (can be quite a few megs!) What I am missing is the one specific feature – I want the UI to clearly spell out the name of the person who broke the build (and speak it very loudly using text-to-speech, but that could be considered too esoteric to be included in the main build but rather implemented as a plugin).
3. Impressive code duplication finder – buggy at first, it now semi-stabilized. While we haven’t had the time yet to actually work with it and remove duplications from our code base, it’s just a matter of internal priorities at Delver. The power this gives a developer that wishes to improve his code base is huge.
4. VC integration – a bit less smooth than the other features. It’s mostly worked for me, but sometimes it didn’t. The Personal Build feature is very attractive, but I found one major problem using it: I ran a personal build that succeeded, but then it failed to automatically merge the code. I don’t know if anything can be done about this – I can GetLatest before running the build, but the content of the branch may still change, and unless the merge is automatic human will be needed to solve it. However, I think it’s a powerful tool that should work most of the time.

That’s it for now. All in all, great product – keep it up JetBrains.

Funny – just today I read that the great Donald Knuth, in a recent interview, dissed unit-testing:

“As to your real question, the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”

(In this interview he also talked against multi-core paradigm (which may be the only way to keep up with Moor’s law due to our CPUs getting hotter and hotter), but that’s a different story).

Why is this funny? Because just today at work I installed JetBrains’ TeamCity – a very fine unit test and automated build suite. Sadly I didn’t have time to finish configuring it today, but I already see the great benefit this will bring to all our development team. It goes beyond a simple automated build system (which is important enough, making sure no member of the team messes something up by accident, opening up new venues for brave code refactoring).

TeamCity aims to take all resource-intensive activities off the developer’s computer. Just some of its features are (I didn’t have the chance to test them, but I believe JetBrains – these are the guys that make Resharper after all):

• Code Analysis (finding code and style errors)
• Code Duplication – automatically find the copy-pastes I hate so much, with configurable granularity (java only, coming soon for .NET)
• Pre-commit Build – Suppose it is now 8PM, you’re about to leave for home, and unfortunately you have a rather large piece of uncommited (checked out) code. What do you do? You do not commit the code. Why? Because there’s a good chance it will screw up the build and you don’t want to leave the common integration area messy. To the rescue comes the Pre-commit Build feature – you can commit the code, have TeamCity catch your commit before it actually happens, test it automatically on a build agent (dedicated build machine), and then only if the code compiles and all tests pass it will check in the code for you. You do not have to wait for tests anymore! This frees up developer’s time for actual development, while preserving the high benefits of unit-testing (that Knuth doesn’t see, for some reason).
• I’m sure it has load of other features I haven’t dug up yet – among them the ability to run tests without any commit process “just for fun”, it’s ability to smoothly handle multiple Agents (each running a configurable number of builds concurrently), supporting multiple source controls, IDEs and development languages, ICQ/RSS/Jabber support, and last but not least a button “Run this test on the fastest available test machine”.

So far the systems I’ve used for unit-testing were:

1. Manually running unit-tests a couple of times, then forgetting about them 🙂
2. A patched-up system that automatically runs tests for you on checkin, with a build status indicator that Gal Golan in my development crew in the army wrote himself
3. CruiseControl.NET – an open source project that does something similar to the above, only slightly more configurable

As you can see by the length of this post, I’m excited to try on a professional solution to this problem for once 🙂 And for those of you that got this far, let me add that it’s free or charge – for up to 3 Build Agents and 20 developers. Huzza!