TeamCity
Powerful CI/CD for DevOps-centric teams
Opening TeamCity 7.0 EAP (build 20184)
Look out world, we have just opened early access program for the next TeamCity version: code name Faradi. That means you can download the first TeamCity 7.0 build right away and try all the cool features that are in it. Want to know what features are there? Here’s a list:
Build Failure Conditions – Smart Control Over Your Build Status
TeamCity has become smarter in deciding when a build is to be considered “failed” – now it can look beyond the obvious like exit code or failed tests presence. Basically, you can instruct TeamCity to mark a build as failed if it has become “worse”. There is a number of metrics in TeamCity already to measure how “good” a build is, like code coverage, or artifacts size, etc., so all you need now is set up the threshold for those metrics that are important to you. For instance, you can mark build as failed if code coverage or code duplicates number is worse than in the previous build. Learn more about this feature from the related post. However, that’s not the end of the story. Another build failure condition is on its way – it’ll allow to mark build as fail when a certain message is met in build log. This functionality is still quite raw though.
By the way, don’t panic when you don’t find good old “Fail build if” conditions that used to be at the General Settings page – we didn’t drop them, just moved to the new page with the rest.
Agent Pools – Better Agents Management
Starting with TeamCity 7.0 it’s easier to organize your build agents and calculate the required agents capacity. Instead of having a a single set of agents, you can now break it into smaller groups called agent pools. In two words, a pool is a subset of agents to which you can assign projects. Thus you can run your project on a subset of agents and make sure no other projects will run in the same pool.
Dependency Based Test Run – Faster Builds
Maven, Gradle and IntelliJ IDEA Project build runners now support dependency based run of tests. One of the best practices in software design is to make modules as independent as possible, and if you follow this practice, now you can get an extra bonus – faster builds in TeamCity, because TeamCity can run only those tests that are really affected by changes in dependencies.
Learn more in the release notes.
NuGet Support
TeamCity now comes with native NuGet support. The plugin that provides NuGet support has become available a couple of weeks ago, and now it is bundled with TeamCity. There was a series of blog posts dedicated to this plugin, so we won’t go into details here:
- http://blogs.jetbrains.com/dotnet/2011/08/native-nuget-support-in-teamcity/
- http://blogs.jetbrains.com/teamcity/2011/07/20/nuget-plugin/
- http://blog.jonnyzzz.name/2011/07/nuget-publish-build-runner.html
As a side note, the plugin is compatible with TeamCity 6.5, so if you want to use it in your existing production server, you can download it at teamcity.jetbrains.com.
And a bunch of other features…
… including build performance monitor, improved My Changes page and Build Log, support for Subversion 1.7 in Visual Studio Addin, and so on. See the complete release notes, try the build and share your feedback with us!
Don’t forget to back up your TeamCity instance, and note that starting with this version TeamCity server and agent require Java 6.0 or later.
Stay tuned, we’ve just got the ball rolling!
Subscribe to TeamCity Blog updates
