Comments on: Why pay for a Continuous Integration server? http://blog.uncommons.org/2006/12/08/teamcity/ Rants and opinion interspersed with awe-inspiring tales of heoric software engineering endeavours. Thu, 21 Aug 2008 14:44:07 +0000 http://wordpress.org/?v=2.6 By: New Adventures in Software » Why are you still not using Hudson? http://blog.uncommons.org/2006/12/08/teamcity/#comment-1409 New Adventures in Software » Why are you still not using Hudson? Fri, 09 May 2008 20:55:34 +0000 http://blog.uncommons.org/?p=7#comment-1409 [...] IDEA 6.0 and opened my eyes to a world beyond the fairly basic functionality of Continuum. I was impressed (pre-tested commits are a neat feature), but because you needed licences for every user, I was [...] [...] IDEA 6.0 and opened my eyes to a world beyond the fairly basic functionality of Continuum. I was impressed (pre-tested commits are a neat feature), but because you needed licences for every user, I was [...]

]]> By: Dan http://blog.uncommons.org/2006/12/08/teamcity/#comment-4 Dan Mon, 14 May 2007 17:55:19 +0000 http://blog.uncommons.org/?p=7#comment-4 It's certainly not perfect, but I was impressed by its potential. This posting is from 5 months ago (it's just resurfaced because I moved sites). I think Bamboo had not been released at the time. I haven't had a chance to try it, and I doubt I will any time soon, simply because I'd have to pay for a licence. The advantage of TeamCity is that it was free. JetBrains also provided a free upgrade to 2.0, which is a definite step forward on the 1.x series. One of the original responses to this posting (unfortunately lost in the migration), suggested Parabuilder as an alternative. It’s certainly not perfect, but I was impressed by its potential. This posting is from 5 months ago (it’s just resurfaced because I moved sites). I think Bamboo had not been released at the time. I haven’t had a chance to try it, and I doubt I will any time soon, simply because I’d have to pay for a licence. The advantage of TeamCity is that it was free. JetBrains also provided a free upgrade to 2.0, which is a definite step forward on the 1.x series.

One of the original responses to this posting (unfortunately lost in the migration), suggested Parabuilder as an alternative.

]]> By: Robert http://blog.uncommons.org/2006/12/08/teamcity/#comment-2 Robert Mon, 14 May 2007 12:39:06 +0000 http://blog.uncommons.org/?p=7#comment-2 You pay if you see value. There certainly are tools out there that can provide the value. TeamCity, though, has some _very_ rough edges. I draw the line at a tool that can neither tell me exactly what the compile error was, or what unit test failed, or give a meaningful view of the running build log OR even use a released version of Maven to do the building! Furthermore, the agent structure, while nice on paper, has some problems - imagine a "staggered" build process where you do one phase of the build, which triggers the next, and so forth; the agent structure makes it difficult for you to have all the builds on one box BUT have the first build kick off on any available agent. These staggered builds are useful for getting good feedback during longer builds (not to mention taking better advantage of a grunty build server), but doing it under TeamCity negates the point of the build grid in the first place. TeamCity is also desperately in need of some sort of version control on the configuration, as well. One of the best aspects of CruiseControl is that you can place the build configuration in version control - making it easy to keep track of what is happening to the build environment. It's very annoying (speaking from experience) to spend an hour or two diagnosing a broken build only to realise in the end that someone had changed the config options. There's also a hidden catch in the TeamCity licensing to watch out for - if you decide (for whatever reason) you want to have multiple TeamCity central servers, you'll find that the licensing is per user per server; you can't have the same user/license on multiple servers. Depending on how many builds you want to manage (and how you want to manage them), this may be an issue. Finally - that "remote build" option can also introduce the sort of problems about flow control that it's meant to prevent. You kick of a remote build, you get involved in some other work, and then you notice a bit later the remote build failed. Well, now you've got to fix it - which might just mean you need to get your environment back to the state it was when you kicked off the remote build (IntelliJ gives you no easy way to do this, let alone to get you back to your work state again AFTER you fix the bug). If the build took a long time to get to a breaking point (and if you've got fast builds, you don't need this feature!) you can easily lose an hour or more of work because of a silly broken build. By contrast, if it was committed, the worst case would be you check out the code in a new work area and fix it there. (BTW, with Subversion at least, there's an easy way to avoid the problem of checking out broken code - do 'svn up -r ) Oh, and this was all with version 1.2. :) It's not that TeamCity doesn't have some nice features, it's just that it's very rough. Compare it with Bamboo - similar price for a 10-person team (ignoring the IntelliJ discount), but Bamboo is a lot smoother. Not as many features, but the features they do have are a lot better thought out, and much better implemented. (BTW - I'd happily pay $500 to not have to use IntelliJ - give me Eclipse any day. And yes, I've got access to both, so it's not just a case of sour grapes. IntelliJ is just clunky to use) You pay if you see value. There certainly are tools out there that can provide the value.

TeamCity, though, has some _very_ rough edges. I draw the line at a tool that can neither tell me exactly what the compile error was, or what unit test failed, or give a meaningful view of the running build log OR even use a released version of Maven to do the building! Furthermore, the agent structure, while nice on paper, has some problems - imagine a “staggered” build process where you do one phase of the build, which triggers the next, and so forth; the agent structure makes it difficult for you to have all the builds on one box BUT have the first build kick off on any available agent. These staggered builds are useful for getting good feedback during longer builds (not to mention taking better advantage of a grunty build server), but doing it under TeamCity negates the point of the build grid in the first place.

TeamCity is also desperately in need of some sort of version control on the configuration, as well. One of the best aspects of CruiseControl is that you can place the build configuration in version control - making it easy to keep track of what is happening to the build environment. It’s very annoying (speaking from experience) to spend an hour or two diagnosing a broken build only to realise in the end that someone had changed the config options.

There’s also a hidden catch in the TeamCity licensing to watch out for - if you decide (for whatever reason) you want to have multiple TeamCity central servers, you’ll find that the licensing is per user per server; you can’t have the same user/license on multiple servers. Depending on how many builds you want to manage (and how you want to manage them), this may be an issue.

Finally - that “remote build” option can also introduce the sort of problems about flow control that it’s meant to prevent. You kick of a remote build, you get involved in some other work, and then you notice a bit later the remote build failed. Well, now you’ve got to fix it - which might just mean you need to get your environment back to the state it was when you kicked off the remote build (IntelliJ gives you no easy way to do this, let alone to get you back to your work state again AFTER you fix the bug). If the build took a long time to get to a breaking point (and if you’ve got fast builds, you don’t need this feature!) you can easily lose an hour or more of work because of a silly broken build. By contrast, if it was committed, the worst case would be you check out the code in a new work area and fix it there.

(BTW, with Subversion at least, there’s an easy way to avoid the problem of checking out broken code - do ’svn up -r )

Oh, and this was all with version 1.2. :)

It’s not that TeamCity doesn’t have some nice features, it’s just that it’s very rough. Compare it with Bamboo - similar price for a 10-person team (ignoring the IntelliJ discount), but Bamboo is a lot smoother. Not as many features, but the features they do have are a lot better thought out, and much better implemented.

(BTW - I’d happily pay $500 to not have to use IntelliJ - give me Eclipse any day. And yes, I’ve got access to both, so it’s not just a case of sour grapes. IntelliJ is just clunky to use)

]]>