TeamCity Tryout
I’m doing a gig for a local company (a non-software company) that is trying to build a development team. My job is two-fold: 1. help them get some software up and started so they have something to build on, 2. train their current staff (consisting of one developer) on good patterns and practices for software development.
The project is interesting and the people are pleasant, not a bad gig at all. So far I’m manage to put source control in place (SubVersion via the VisualSVN Server — they really have the best install around for windows), they are getting on board with TDD, I’m slowly working in User Stories into their process (by osmosis really), and I decided to try to go the extra mile and get a bit of Continuous Integration going.
In the past I would have hit up CruiseControl, struggled for a few days, swore, kicked a couple of dogs, and then get everything working. This time I thought I might be able to spare the dog by trying TeamCity from JetBrains. Result, the dog got an extra treat this week.
I got the entire friggen process up and working in about three hours. And that was on the first try! Most of that time was spend fixing dependency issue in the projects (which were my fault, not TeamCity’s — that is why you want one of these things after all).
The first process I set up was to create a test build. The test build did these things:
- Monitor Subversion to changes in my project, if there are changes, downloaded them and proceed to step 2. Otherwise: repeat step 1.
- Compile all the source. I chose to build the project from the solution file. If this were an internal project I might use a Nant script, but considering the client I just stuck with the solution file.
- Run all unit tests. Report any failures.
- Let me know all is well.
For #4, I had to log onto the TeamCity web site (created by the install), and install the client task tray application (similar to CC.Tray for CruiseControl really). The only annoyance with any of the tools is that the TeamCity tray application doesn’t make any noise, and it isn’t very configurable (like CCTray is).
But, for an extra bonus step I set up a second build to recreated the test web site on command. This second build took 30 minutes. The TeamCity’s configuration web site has an option to copy an existing build. I made a few modifications and I was good to go. The two modifications were: change the build directory, and no to monitor subversion for changes. I want this build to be kicked off manually.
So now, the only part of the process that is not automated is the move to production. I have to make web.config changes for that (meaning I have to do some custom msbuild work to swap connection strings). But all in all I am very happy with where things are at considering the amount of time spent.
CruiseControl might be more configurable and have a better tool set, and for a different project on a different team, I might go down that road again. But for an inexperienced team, or for a project with non-demanding build requirements, TeamCity is an excellent tool.
I am officially a TeamCity convert.
I’ve read a lot of recent blog postings that complain about how difficult CC is to setup. I disagree. I am confident that I could set it and a project up in 30 mins. However I do agree that CC’s XML configuration is a pain.
I too was planning to setup a test instance of TeamCity because, as you well know, I am strong believer in playing with new toys. Are there any features or usability enhancements beyond what you describe above that would warrant choosing TeamCity over CC for a more experienced team?
Have you tried to configure notifications for windows tray notifier? There is a lot of functionality behind them.
@Pavel Sher: yes I tried, but it is missing the one feature I want: play specified mp3 when the build fails.
It is a bit strange thought, on the administration side, that you have to connect to the server to tell the client which projects to monitor. Not bad, just strange.
@Jason: for you, yes. You could set up CC in 30 minutes. For me: 30-45 minutes. But, the real problem is after I leave my current gig. If I have to explain how something works, it is easier to explain how to setup and work TeamCity.
The administration for TeamCity is through a web UI that you already connect to to get the build status. Want to change how the build work? No problem, just click the Administration button in the header.
Administration for CC, as I remember it, involves using Terminal Services to connect to the server, finding a config file, and changing a bunch of xml.
So, the real difference that I would use to characterize the two build systems: CC takes more knowledge ahead of time to work and modify, and TeamCity is easier for beginners. CC is probably a bit more configurable that way, but TeamCity is lacking for options either.
Actually, one cool feature that TeamCity has, and I don’t know how you could do this on CC is the Agents. You can load an agent onto a bunch of machines, the agents are what actually builds the projects, and suddenly you have a partially distributed build environment. Now all things considered, only 5% of the user base will need this feature, but it is cool that it is already built in.
Now, once everything is setup and running, what are the usability differences? They are about the same. I actually think I can navigate through TeamCity a bit faster than CC, but I haven’t really tested that notion yet.