Posts Tagged ‘agent’

Continuous Integration for PHP using TeamCity

Monday, February 25th, 2013

TeamCity supports your Continuous Integration (CI) process in many technologies like Java and .NET. It’s not because we don’t provide other technologies out-of-the-box that you can not make use of them! In this post, we’ll put TeamCity to the test and setup a CI process for a PHP project.

We’ll be using the open-source PHP project PHPExcel as a sample project to set up Continuous Integration using TeamCity. This project features a large amount of code, PHPUnit tests and uses Phing to create build artifacts. We’ll use TeamCity to get this process completely automated and ready for immediate feedback once the source code on GitHub changes.

(more…)

Opening TeamCity 7.0 EAP (build 20184)

Thursday, September 1st, 2011

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:

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!

Build Agent API Changes

Monday, October 4th, 2010

After our posts about TeamCity’s new multiple build steps (previously called “multiple build runners“) feature and further changes in .NET build runners, I believe that plugin developers might have some questions to be clarified.

So today, I’m going to shed some light on the major agent-side API changes that we’ve made to support multiple build steps. I hope this post will help you to painlessly improve your build runner plugins.

AgentRunningBuild interface no longer represents parameters for a build runner. We’ve introduced new interface BuildRunnerContext that provides parameters for build runner. Starting with TeamCity 6.0 AgentRunningBuild will only describe a build.

Note that there is no getter for BuildRunnerContext in AgentRunningBuild. AgentLifeCycleListener interface now provides BuildRunnerContext in build step related methods.
We’ve added runnerFinished event and updated almost all build-related events signatures to contain AgentRunningBuild and BuildRunnerContext instances. So, in most cases one will not need to cache those instances in a plugin code.

So if you ask yourself, what to do to improve your build runner, the answer is simple. If your build runner is implemented by extending CommandLineBuildService, you need to extend BuildServiceAdapter abstract class. This class contains all getters for all parameters you may need in build runner implementation.

Of course, this post doesn’t cover all the details, but only gives general tips. So don’t hesitate to ask questions, I’ll be glad to answer.