I have worked with Team City (TC) on a project and so would like to share my opinion on TC. This project wasn’t long enough for me to get to see all aspects of TC but it was long enough to be able to evaluate it, at least not in a too shallow manner.
The project I worked on was a Sitecore 8.1 MVC Web Application that implements Helix standards. We used Team City to deploy the project to our staging machine.
Getting Team City
My first comment on Team City (TC) is that it is expensive! I was overwhelmed with the prices when I was navigating through JetBrains’ Team City page. I’ve heard a lot about Team City but got frustrated when I saw the ‘Licensing’ word. However, luckily, there was a free version.
This free version is not bad at all. 20 build configurations, “full access to all product features”, “support via forum and issue tracker” and 3 build agents! What more can I ask for? It was really awesome to see a proprietary software having a free version with features that small to mid-sized companies wouldn’t need more.
TC supports multiple platforms! You can download a version of TC for Windows, MacOS, Linux and Docker. Supporting all common platforms is quite crucial for CI tools, because a lot of projects and companies rely on Linux or Linux-based OS. In addition to the fact that other well known CI/build tools support multiple platforms such as NAnt and Jenkins.
Installing Team City
Installing TC is quite standard using the usual installation wizard with the addition of 3 customized pages: 1) prompt to install TC server and/or build agent 2) TC server port number 3) build agent configurations:
- the setup prompts you to install TC server service on its own, TC build agent on its own or both of them
- TC server port’s default number is 8080 but you can change it on the second step
- finally, it prompts you to edit the default build agent configurations such as the just installed server url, the build agent’s own port number and the locations of the build agent’s data folders
At the end of the installation, you should have two new services installed: 1) Team City Server and 2) Team City Build Agent.
The installation part of TC is quite simple and straightforward. However, you may face an issue with the build agent being not configured correctly. I ran through the installation several times, and one of them failed to configure the build agent and I had to research what to do and I ended up re-installing and configuring the build agent manually.
Some of Team City Features
I will not be able to talk about or even mention all TC features, however, I will try to mention at least the major ones that I happened to come across.
Server / Build Agent Separation
Although this may seem an overhead in some cases, it also provides an advantage of separating the build server from the reporting (web) server. This is useful when a large company has several large projects that each need a powerful machine. So this provides the ability to distribute the projects over several build servers while still being able to view the builds statuses from one server/site.
A project is considered a build configuration in TC since I could create several build configurations under one TC project, each with different parameters or build steps.
The build agent is the service that is responsible for going through the build steps for projects and providing the build output for them. The server is responsible for receiving build statues from build agents across different servers (or the same server) and providing the reporting interface for the users (TC website).
The free plan provides up to 3 build agents, so as you can see this is more than enough for most small to mid-sized companies. Keep in mind that a build server doesn’t mean one project. A build server can be responsible for building several projects. The free plan allows for up to 20 projects (build configurations).
In conclusion of this feature, this is such a useful and important feature for a CI/buid tool. It always scalability of the CI/build process and more control when there is a need to distribute computation power. On top of this, it is relatively really easy to set up. You only have to open the web portal from the new build machine and download a new build agent installation file. At the end of the installation provide the server URL and that’s it.
Treating build failures as tickets
When a build fails for whatever reason, TC provides an ‘Investigation’ section where you can choose to start an investigation, assign this failure to yourself or someone else, added comments on this failure and mark it as resolved once the investigation is complete.
This feature allows for proper responsibility management for build failures. The team leader or project manager has this information of who is investigating this issue and can follow up directly without the need for whole team emails.
Availability of information right when you need it
TC provides the user with lots of useful information everywhere, notably with build failures where you can always see the related info about the failure: the build number, the build date, the build machine, who is investigating it (if any), the history of builds, the change log (sourced from source control system), who was responsible for that latest change etc… This information is usually available right when you needed, with at most one or two clicks and lots of times without reloading the whole page.
There are also two buttons available at the top right corner of every page inside a build configuration pages from which you can start a new build, start a custom build (where you can choose the build agent options, the commit to build on and other parameters options), pause the triggers that start new builds, check if there are new changes that have not been built yet and enforcing a clean checkout before running a build. So appropriate shortcuts are usually available right there for you.
This feature is applicable on most pages in TC. However, this may also make pages a bit messy and overcrowded with buttons, links and clicking options. I sometimes find myself lost trying to pinpoint the specific information that I need or trying to navigate to different parts of the system, which leads me to the next point: Navigation.
Navigation in TC
This is what I hate most about TC. Navigating around is so frustrating. Most pages are filled with details and so many pages look alike for the first moment which makes you feel lost.
The other part of this problem is that when you need to go to a specific page, even after configuring several projects, I still find it hard to navigate to that page from the first attempt, especially settings pages. There are settings for TC, settings for the main project and settings for each build configuration in addition to settings for specific features. For each of the above, the settings links are on different parts of the page surrounded with many links and options, and when many Project pages look similar to build configuration pages you’ll immediately feel lost.
Obviously, this is not a critical or major issue, plus after hours of playing around in TC, you’ll eventually get the hang of it and be able to navigate around quickly.
Creating a build configuration is easy and very customizable
Creating a build configuration starts with letting you choose your version control and entering the version control settings to start getting your code. Once of the really cool features of TC is that it then tries to suggest your next building step but examining your files. For example, for my Sitecore MVC project, it suggested creating a visual studio build step for each of my solution files, a PowerShell build step for my PowerShell scripts files (*.ps1) and an msbuild step for my publishsettings.targets. I was disappointed that it didn’t suggest restoring NuGet packages, or installing npm locally or creating a gulp build step. But I do not want to ask too much of it so I’m glad about what I got!
Adding new manual steps is also not too difficult. TC by default provides an excessive list of build options that include common tools such as Gulp, Grunt, Nant, NodeJS, npm, command line, PowerShell, NuGet, NUnit, VS tests etc…
After creating your steps, you would be able to see an overview of all your build steps which include brief details about each step, which is quite neat. Reordering steps is also really simple to do.
One thing that I needed but couldn’t find is preventing a build from failing due to the failure of a specific step.
Creating triggers to start your build is also as simple. There are several types of triggers that include VCS (Version Control System which is triggered when a new commit is detected), simple schedule trigger and some other triggers that depend on other external tools.
TC also provides more customizations with Failure Conditions, Build Features, Dependencies or the build configurations, custom Parameters and Agent requirements in case your build needs build agents with certain requirements such as being installed on a machine that has a certain software installed which your build depends on.
In conclusion of this feature, I really like creating a build agent. It is easy and contains lots of cool features and options that I haven’t seen in other software. The user interface of forms, by the way, is easy to use and interact with.
Other minor features
“TeamCity *.*.* has been released. Upgrade!”. Although I’m using the free plan, every few weeks I get a message that the latest TC has been released and I could upgrade with a click of a button.
TC provides lots of statistics for Projects and build configurations that are quite informative.
You can watch a build agent as it is building a project with the output of each step being refreshed every few seconds.
Many simple features/options/shortcuts that are difficult to mention that makes your experience easier, such as hiding successful projects/build configurations for the overview pages, archiving projects, filter options, pinning specific builds etc…
I really like Team City. It is packed with awesome and brilliant features and options.
- It easy quite easy to use, configure and customize.
- Its free plan is very satisfying.
- Interacting with the UI of forms is friendly
- JetBrains’s Online documentation on TC is one of the best documentations
- TC community has become very large and help is found anywhere online
However, as I mentioned earlier, the general look and feel of TC is boring, a bit overcrowded, messy and not attractive in addition to the Navigation maze that you’ll experience for the first many hours.