How does your continuous integration work?

Question

I'm building a CI server and would really appreciate to get real experiences, and an overview on what are people using.

So, what are your build processes? Is there something like:

• one hourly for code and tests,
• another daily for build msi and code metrics,
• etc.,

and also, what does your complete build process use? Do you use something like:

• team city,
• msbuild,
• nunit - for tests,
• ncover - for test coverage,
• ndepend - for code metrics,
• sandcastle - for documentation by the code comments,
• testcomplete - for QA tests,
• etc.?

Share! ;)

Answer 1

On my previous project we used to have two luntbuild servers plus an SVN server.

First luntbuild machine was used for building the project - incremental build + unit tests per each commit and then clean build + unit tests + complete install packaging during the night.

Second luntbuild machine was used as a testing rig for integration testing. As soon as the first machine finished building the nightly install it would pick that up, deploy it on itself and the run the full suite of integration tests (junit based driver of swing gui), so each morning testing engineers would get an install along with a report of a sanity check so they could decide if they want to take the new build or not.

Answer 2

We're using CruiseControl.net as our CI server in combination with nant. Most builds (we have around 30 builds) are triggered on changes. Some less important heavy builds are only triggered once each night, this also goes for the maintenance builds which clean most of the normal builds.

For our C/C++ code builds we're using a proprietary build system that is able to distribute code builds to every machine available in the company (like IncrediBuild, but much more flexible). For our C# builds we directly call devenv.com, but we use NUnit to run the unit tests. Our C++ unit tests are using our own framework, running them results in xml that's very similar to NUnit's. For some extra code checks we run pclint each night. For now, no code coverage is done yet, which is a bit of a shame.

We're also using the system to prepare the finals build of our product. It's just the first step, it still needs some manual actions afterwards.

Regards,

Sebastiaan

Answer 3

We had a similar conversation at the most recent CITCON North America (Continuous Integration and Testing conference) where we all shared our experiences and tried to put together a road map from simple CI to very built out CI and release systems.

The original conference notes are here. Along with a Flickr photostream. A cleaned up version is available at the urbancode blog as well.

The Aussies revisited the topic at CITCON Brisbane and a pencast of that is available

Hope some of those resources are useful.

Answer 4

Build Processes - we have 4 currently active branches of a large code-base that we run builds for continuously. For each branch we have the builds broken down into two stages:

• Quick Continuous Integration build that runs after every commit so that we can get feedback about broken code, or broken tests as quickly as possible
• Full automated build that runs twice each day that guarantees that the code will build from scratch start to finish.

Our build process is coordinated by Zed Builds And Bugs and includes Ant, Make, Maven, JUnit, Findbugs, shell scripts (historical), across Windows, Linux, AIX, HP, and Solaris.

We are currently in the process of including more roll-ups of historical trending and statistics so that we can see from a higher level how the dev process is going.