TeamCity Blog

As we mentioned in our previous blog post, TeamCity has a number of ways to verify the code quality. Searching for repetitive blocks of code - known as code duplicates - is one of them.

The redundant and seemingly harmless pieces of code may eventually lead to an unmanageable project code base. Our own team is a really good example: searching for code duplicates in the IntelliJ IDEA project locally took about 40 minutes, and it was almost impossible to constantly monitor the state of the code base. But as soon as we implemented the server-side search for code duplicates:

• all of the team members had access to the duplicates report and could make the code base better structured and controlled;
• unnecessary pieces of code were removed, thus reducing the overall size of the code base;
• the code base became much more manageable;
• the developers were able keep on coding as usual because the duplicates were searched for on the server, and their own machines resources were not used.

TeamCity has supported searching for Java code duplicates for quite some time. Support for finding C# duplicate code will be available in TeamCity 3.0. We are working on the possibility of configuring the Java duplicates finder to work not only via an IntelliJ IDEA project file, but also by using the Eclipse project file or a Maven POM file. Setting up a build configuration with the Duplicates finder runner ensures that all of the integrated code is constantly checked for duplicates.

When specifying this runner settings for Java projects, you need to point TeamCity to the project .ipr file and set a number of options, in particular:

• searching or ignoring the duplicates in the test sources of your project if it does not make much sense to verify tests for duplicates
• whether to regard usages of different variables, fields, methods, types, or literals in otherwise structurally similar code as duplicate
• the minimum relative size/complexity of a code piece that will be regarded as a duplicate

The duplicates search is, as usual, performed on one of the available build agents, and when a build is finished, a detailed report is available in the web UI. Working with code duplicates results is similar to working with the server-side inspection results: after the build is finished, you can browse the duplicates list (build results page, Duplicates tab) and opt to show all or only the newly discovered duplicates.

The top left panel displays a list of found duplicates and their instances with the file names. Use the arrows to examine the selected duplicate in one of the lower panes.

From the duplicates report page you can jump to the source code in your IDE (IntelliJ IDEA, Eclipse or Microsoft Visual Studio). Click the Open in active IDE button, and you will navigate directly to the file containing the duplicate instance and be able to quickly revise the issues found. In IntelliJ IDEA you can work with found duplicates either in the editor or in a tool window.

Keep an eye on our Early Access Program!

View the example of a server-side duplicates search at our demo site.

Technorati tags: TeamCity, JetBrains, IntelliJ IDEA, Eclipse, MS Visual Studio, Java, C#, continuous integration, build management, agile development

TeamCity has an unparalleled variation of means for maintaining code quality:

• search for duplicated pieces of code for Java and .NET projects (.NET support is now available in TeamCity 3.0 EAP)
• server-side code inspection of Java code (more than 600 IntelliJ IDEA’s inspections are used)
• analysis of Java code covered by unit tests

With server-side code inspection the whole project codebase is tested as often as you need. The developer’s machines are kept free, so no real development time is stolen. All the developers’ changes to the source code are integrated into the codebase are checked to make sure that they conform to coding standards and guidelines. Besides, TeamCity detects probable bugs, pieces of “dead” code, performance issues and supports many technologies including EJB, JSP, and JSF.

To inspect your code remotely on the server-side, set up a build configuration with the Inspection build runner and point it to the IntelliJ IDEA project file (the detailed procedure is described in TeamCity reference):

After the build is completed on any of the preconfigured build agents, TeamCity allows you to review the inspection results in the web UI (the build results page, on the Code Inspection tab). You can then quickly navigate to the file containing the issue found in your IDE (IntelliJ IDEA and Eclipse are supported).

You have the option to browse all or only newly introduced code problems as well as filter the problems considered errors.

The server-side inspection results can be downloaded into IntelliJ IDEA, thus, you don’t need to switch to TeamCity’s web interface to review the code inspected: from the TeamCity menu, choose Code Inspection. Then you can view the inspection results in the editor and apply quick-fixes (solutions for discovered problems) or work with inspection results in a toolwindow. It’s up to you and depends on your IntelliJ IDEA working habits.

To sum things up, the server-side code inspection has a number of pros:

• developer’s machines are not slowed down and the feedback loop becomes much shorter
• project code quality is maintained during the project’s entire lifecycle
• integration with IntelliJ IDEA provides ideal web-IDE navigation possibilities
• quick-fixes let you solve most problems on-the-fly

View the example of server-side code analysis at our demo site.

Technorati tags: TeamCity, JetBrains, IntelliJ IDEA, Eclipse, MS Visual Studio,continuous integration, build management, agile development, monitoring

Until now the build configuration used VCS roots that were defined in the project. Numerous TeamCity users asked for more flexibility when setting up the VCS roots, so we decided to make a number of refinements in this area. You asked, and we listened.
First and foremost is that in TeamCity 3.0 you can define VCS roots for any build configuration of your project, and the build configuration’s VCS roots settings are independent of the project. Specify any number of VCS roots when you create a new build configuration or edit the existing ones:

Another neat feature is shareable VCS roots. Once you decide to use the same VCS root for a group of your projects, you eliminate a bunch of redundant operations. This option is set when you specify the general settings of a build configuration:

Technorati tags:  TeamCity, VCS, VCS roots, JetBrains, IntelliJ IDEA,continuous integration, build management, agile development

TeamCity has multiple ways to monitor a projects health. First and foremost is, of course, the user dashboard. Then come the plugins for the IDE’s that TeamCity currently integrates with (IntelliJ IDEA, MS Visual Studio, and Eclipse), standard e-mails, Jabber/XMPP protocol instant messages, and the Tray Notifier. But all these methods require either a TeamCity login, or some installation and customization procedures.

We decided to make it easy for software development teams to let their customers and other outsiders (who are not interested in the build process) monitor the builds’ status. No special magic - just insert a small HTML fragment into any web page:

• company’s website,
• blog,
• Wiki,
• Confluence.

And get an overview of the current project status: the latest build results, its ID, date and a link to the latest build artifacts:

This “version” of the projects dashboard does not require a login of any kind and of course the builds’ status is being constantly updated.

To start using this feature you have to either create a new build configuration or edit the general properties of an already existing one and select the Enable status widget option. The cues on the HTML sources to paste into your web pages are, as usual, in the TeamCity online reference.

Technorati tags: TeamCity, external status widget, JetBrains, IntelliJ IDEA, Eclipse, MS Visual Studio,continuous integration, build management, agile development, monitoring

TeamCity’s Build Agents run the software builds and altogether make the company’s Build Grid. To be able to run some build, the Build Agents must meet the requirements of the build configuration. If there is a free build agent matching the build configuration requirements is found when triggering the build, the build is started. Otherwise the build enters the Queue and is processed when a compatible build agent becomes free.

In TeamCity 3.0 you can establish a run policy for different build configurations selecting to run:

• only specific build configurations
• all build configurations compatible with the build agent

Such approach as we believe will allow to manage the build agents’ workload more effectively. Lets look at a quite common situation: if performance tests (as a rule taking much time) are run, the build agents which have low hardware resources may slow down, more builds will enter the build queue, and the feedback is not so quick as you would like it to be. To avoid such situation, define the run policy for the build configurations which can be run on the build agent. Do it when setting up the project or build configuration and any moment you need:

1. Click the Agents tab.
2. Navigate to the desired build agent.
3. Click the Compatible Configurations tab.
4. Select Run selected configurations only and tick the desired build configurations names to run on the build agent.

The changes are applied on the fly as usual.

And vice versa: you can make the build agent name or property a must-have requirement for the build configuration. As a result, TeamCity will create builds of the build configuration only on specific build agents.

More details on this are available in TeamCity online reference.

Technorati tags: TeamCity,build agent, build queue, JetBrains, IntelliJ IDEA, continuous integration, build management,agile development