Continuous Integration for Everybody
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.
Martin Fowler
TeamCity is a user-friendly continuous integration (CI) server for professional developers and build engineers, like ourselves. It is trivial to setup, manage and use. It scales perfectly for a company or a team of any size.
TeamCity is absolutely free for small teams.
TeamCity helps you:
- Automate code analyzing, compiling, and testing processes, providing instant feedback on build progress, problems and test failures, all in simple, intuitive web-interface;
- Run multiple builds and tests under different configurations and platforms simultaneously;
- Perform Pre-tested commits, helping the rest of a team sustain an uninterrupted workflow;
- Have build history insight with customizable statistics on build duration, success rate, code quality and custom metrics;
- Enable cost-effective on-demand build infrastructure scaling thanks to tight integration with Amazon EC2.
Who uses TeamCity
"TeamCity integrated nicely into agimatec's existing environ- ment. Project configuration was intuitive and easy, with a user-friendly web interface to configure different types of projects, and featured effective Maven integration."
read the case study (61 Kb)
"TeamCity gives us a peace of mind. We know that the build is working and developers won't be delayed (or stuck) as a result of getting the latest versions of the code from the source control system."
read the case study (61 Kb)
.NET developer?
- Build and test any Visual Studio solution, as well as any other project using MSBuild or NAnt build scripts;
- Run tests under any of the .NET testing frameworks out of the box, including: NUnit, MSTest, MSpec, xUnit and all Gallio - based frameworks. Usually, to make TeamCity discover tests in your build, you don't need to change the build scripts;
- Choose any of the coverage engines currently available for .NET: NCover, PartCover or JetBrains dotCover. Again, you do not have to modify your build scripts, just turn coverage on in the TeamCity;
- Work with TeamCity without leaving Visual Studio. Receive build notifications and browse build results in your IDE: all with navigation to the source code, and with code coverage highlighting if you use dotCover.
- Use TeamCity as NuGet feed server, and employ other package management capabilities provided by NuGet — right in TeamCity.
Using Java?
- Get full CI for all of your Ant, Maven or Gradle — based projects with zero modifications to the build scripts. Of course any IntelliJ IDEA project supported by TeamCity as well;
- Run over 600+ automated server-side code inspections for Java, JSP, JavaScript and CSS - out of the box;
- Use JUnit or TestNG for unit testing without having to change your build scripts. TeamCity will let you know about failed tests even before all tests have done performing. And on the next build run, previously failed tests will be run first, thanks to unique tests re-ordering feature;
- Run server-side code coverage with Emma, or with the IDEA-based code coverage framework;
- Find code duplicates in Maven-based and IntelliJ IDEA projects;
- Work with TeamCity from within Eclipse or IntelliJ IDEA.
Ruby Expert?
- With RakeRunner, you can use RVM, Bundler or Ruby SDK to build your projects from TeamCity;
- Run unit tests against your code with any of the publicly available tools, such as Test::Unit, Test-Spec, Shoulda, RSpec, Cucumber;
- If you use JetBrains RubyMine, enjoy the benefits of having fully featured TeamCity integration. Run builds, run Pre-tested Commits, browse build and unit tests results: all without leaving your IDE;
- As with .NET and Java, if you use Mercurial or Git, you can setup TeamCity to trigger Personal Builds on selected branches chosen by a pattern. Such builds would not trigger the success status of the whole project, and you'll be the only person to get notified when it's finished. Personal Builds is a great way to test your changes before merging them to the main branch.