JetBrains TeamCity 1.0 beta
I decided to give the JetBrains TeamCity 1.0 beta a try. JetBrains is the company that makes IntelliJ IDEA, the best Java IDE by far, and TeamCity is their new continuous build tool.
You can download TeamCity as either a WAR or a ZIP, which includes Tomcat. I downloaded the ZIP and unpacked it into a directory on my iMac. It looked like a pretty standard Tomcat layout. I ran the startup script, and (after giving me a warning about a missing work directory) it started up. So far, so good.
I accessed TeamCity on its default port of 8111. The main page appeared and invited me to create a new administration account. What could be easier than that? I didn't have to configure anything beforehand; the software was smart enough to know that the first account created has to be an administrator account.
After logging in, I headed to the Administration page and created a new project. I use Perforce for source control, and TeamCity supports Perforce directly. I created a new client for TeamCity and configured TC to use that client. All I needed to enter was the standard Perforce connection information (server, port, username, password) and the Perforce-style path identifying the sources.
TeamCity supports a lot of different build systems. You can build using an Ant or NAnt (if you are running on Windows) build file, Visual Studio 2005 project (again, Windows only), Maven project file, or IDEA project file. The ability to build using IDEA project files is particularly welcome, since it allows the build to remain completely in sync with an IDEA project. JetBrains promises support for Eclipse project files in a future version. I already had an Ant build file, so I selected that option.
TeamCity keeps track of a build number that increases by one for every build. You can use the build number to identify each build. Unfortunately there doesn't seem to be a way to use any identifier other than the build number. I use Perforce change numbers as my build numbers--a build of some branch is always called somebranch.xxxx, where xxxx is the number of the last change submitted to that branch (obtained using
TeamCity itself is just a web application; it doesn't run any builds. To run builds, you must first download and install a build agent on some machine. There is a link within the TeamCity application for downloading an agent. After you configure and run the agent, it registers itself with the TeamCity web application and can start running builds. You can have as many agents as you want, so a single TeamCity installation could theoretically support hundreds of projects.
You can trigger builds manually, periodically based on elapsed time, whenever code is delivered to the source control system, or some combination thereof. I chose to build the application whenever code is delivered to source control.
When I ran the build the first time, I encountered an error with the build. TeamCity displayed the error message, but strangely, it did not display all of the output from Ant, which I would have expected. The problem was that my build file assumed that the current directory was the directory containing the build file, which was always true when I ran Ant from the command line, but when the build ran under TeamCity, the current directory was the directory containing the agent run script. I fixed that by using a property in my build file to specify the directory of the files that the build file needed. Then I set that property in the project configuration in TeamCity. When I delivered the new build file to Perforce, the build agent started up almost immediately, built the project, and reported success! TeamCity also included, on the build results page, a link to the changes that had been submitted to Perforce and included in the build.
TeamCity will also perform code coverage tests using EMMA and can run IDEA inspections. There is also a TeamCity plug-in for IDEA. I have not explored any of those features yet.
Overall, I am impressed with TeamCity, especially its ease of use. Without reading any documentation, I was able to install the product, create a user account, create my project, and enable builds on delivery, all in less than an hour. Apart from ease of use, TeamCity's other strength is its integration with IDEA, particularly its support for IDEA project files and inspections.
There are a few areas in which TeamCity could use some improvement. Although it can scale to hundreds of build agents, there is no way to organize projects into groups or folders. Something like that would be essential for a large company with hundreds of projects. There is also an assumption, in the user administration pages, that each user will only use one source code repository of each supported type. A complex environment may include multiple repositories of a one type. Of course, the organization could configure one TeamCity installation per repository, but that just forces the user to access more than one application to figure out what's going on. And as I mentioned before, I'd like to be able to use a shell script or Java method to generate the build identifier.
You can download TeamCity as either a WAR or a ZIP, which includes Tomcat. I downloaded the ZIP and unpacked it into a directory on my iMac. It looked like a pretty standard Tomcat layout. I ran the startup script, and (after giving me a warning about a missing work directory) it started up. So far, so good.
I accessed TeamCity on its default port of 8111. The main page appeared and invited me to create a new administration account. What could be easier than that? I didn't have to configure anything beforehand; the software was smart enough to know that the first account created has to be an administrator account.
After logging in, I headed to the Administration page and created a new project. I use Perforce for source control, and TeamCity supports Perforce directly. I created a new client for TeamCity and configured TC to use that client. All I needed to enter was the standard Perforce connection information (server, port, username, password) and the Perforce-style path identifying the sources.
TeamCity supports a lot of different build systems. You can build using an Ant or NAnt (if you are running on Windows) build file, Visual Studio 2005 project (again, Windows only), Maven project file, or IDEA project file. The ability to build using IDEA project files is particularly welcome, since it allows the build to remain completely in sync with an IDEA project. JetBrains promises support for Eclipse project files in a future version. I already had an Ant build file, so I selected that option.
TeamCity keeps track of a build number that increases by one for every build. You can use the build number to identify each build. Unfortunately there doesn't seem to be a way to use any identifier other than the build number. I use Perforce change numbers as my build numbers--a build of some branch is always called somebranch.xxxx, where xxxx is the number of the last change submitted to that branch (obtained using
p4 changes -m1 -i //depot/path/to/the/branch/...). JetBrains could improve TeamCity by enabling it to get the build identifier from an external script or a Java method.TeamCity itself is just a web application; it doesn't run any builds. To run builds, you must first download and install a build agent on some machine. There is a link within the TeamCity application for downloading an agent. After you configure and run the agent, it registers itself with the TeamCity web application and can start running builds. You can have as many agents as you want, so a single TeamCity installation could theoretically support hundreds of projects.
You can trigger builds manually, periodically based on elapsed time, whenever code is delivered to the source control system, or some combination thereof. I chose to build the application whenever code is delivered to source control.
When I ran the build the first time, I encountered an error with the build. TeamCity displayed the error message, but strangely, it did not display all of the output from Ant, which I would have expected. The problem was that my build file assumed that the current directory was the directory containing the build file, which was always true when I ran Ant from the command line, but when the build ran under TeamCity, the current directory was the directory containing the agent run script. I fixed that by using a property in my build file to specify the directory of the files that the build file needed. Then I set that property in the project configuration in TeamCity. When I delivered the new build file to Perforce, the build agent started up almost immediately, built the project, and reported success! TeamCity also included, on the build results page, a link to the changes that had been submitted to Perforce and included in the build.
TeamCity will also perform code coverage tests using EMMA and can run IDEA inspections. There is also a TeamCity plug-in for IDEA. I have not explored any of those features yet.
Overall, I am impressed with TeamCity, especially its ease of use. Without reading any documentation, I was able to install the product, create a user account, create my project, and enable builds on delivery, all in less than an hour. Apart from ease of use, TeamCity's other strength is its integration with IDEA, particularly its support for IDEA project files and inspections.
There are a few areas in which TeamCity could use some improvement. Although it can scale to hundreds of build agents, there is no way to organize projects into groups or folders. Something like that would be essential for a large company with hundreds of projects. There is also an assumption, in the user administration pages, that each user will only use one source code repository of each supported type. A complex environment may include multiple repositories of a one type. Of course, the organization could configure one TeamCity installation per repository, but that just forces the user to access more than one application to figure out what's going on. And as I mentioned before, I'd like to be able to use a shell script or Java method to generate the build identifier.
Comments