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

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 2

For Java, we have an instance of Hudson checking for commits in the SVN repository, for every commit there is a build in which everything is compiled and all the test units are run using Maven2. Also the Hudson is connected to an instance of Sonar which tell us stats about coding style and testing coverage.

Sonar screenshot http://nemo.sonarsource.org/charts/trends/60175?sids=1024412,1025601,1026859,1073764,1348107,2255284&metrics=complexity,mandatory%5Fviolations%5Fdensity,lines,coverage&format=png&ts=1244661473034

Sweet :)

Answer 3

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 4

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.

Answer 5

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.

Answer 6

In my case (an in-house designed/built/supported CB system), commits to the VCS in the tree targeted by a given CB config automatically queue a CB request (multiple requests arriving while a CB is running get collapsed into one, which will run as soon as the current CB process is done).

Each CB instance responds to a CB request by performing the build and test steps it's configured to do (farming them out in parallel to a "cloud" of distributed servers shared by all CB instrances), logging the build and test results, and occasionally (not more often than a configured frequency) launching "heavy tests" (which may run for a VERY long time and will NOT block oncoming CB requests -- heavy tests are forked off completely, though the logs make it very clear exactly against which build they ran).

"sync to head" (that "head" would be "trunk" in other VCS's;-), for dependencies that are not part of the tree tracked by a CB, may happen every time (these would be lightweight, non-production-critical, or experimental builds), or only on very explicit integration requests (that's the other extreme, for "release branches" for builds/projects that ARE production-critical), or with intermediate tolerance.

Not the apex of release engineering practice, I think, but in its range of options it works well for us, for a really wide variety of projects of very diverse criticality, dependency-heaviness, &c;-).

Answer 7

Jenkin is the best tool for Continous-Integration (CI). CI is nothing but the frequently integrating the code in your repository (SCM). Further, Integrating SCM into jenkins for building of your code.

You can set the polling frequency in jenkins. so that, whenever the changes are made and commited in SCM, Jenkins will try to make a build. This way is works.. continous integration.

Answer 8

The CI of Instagram works like this:

At Instagram, we deploy our backend code 30-50 times a day... whenever engineers commit changes to master... with no human involvement in most cases. This may sound crazy, especially at our scale, but it works really well. This post talks about how we implemented this system and got it working smoothly...