Planet SCM

It is official: Parabuild 3.2 Beta is out! We've just announced the beginning of a beta program for Parabuild 3.2, the Continuous Integration and Software Release Management System. Viewtier offers a free license for each new bug found in beta builds!

To join the beta program jump to http://www.viewtier.com/products/parabuild/eap.htm

What's New In Parabuild 3.2

Parabuild 3.2 adds Automerge, an automatic inter-branch merging (integration) for Perforce and over 50 enhancements to its build and release management, build telemetry, user interface, version control integration and notification subsystems.

Other cool things include integration with Checkstyle, PHPUnit, CPPUnit, PMD statistics and build time-to-fix.

Check screen shots and detailed descriptions of the new features.

I have stumbled upon Paul Duval's weblog entry "Continuous Integration is NOT about the CI server". Paul rightfully dismisses CruiseControl as "The" CI server and then proceeds to questioning having becoming a norm interchangeable use of the practice and the tools of Continuous Integration.

I agree with Paul in that it is often forgotten that Continuous Integration is a practice that spells small, often, but meaningful check-ins. Tools themselves do not make Continuous Integration and without the practice are mostly useless.

Yet, Continuous Integration is a lucky case of a practice that is well supported by tools, Continuous Integration systems, which makes it even more powerful. A Continuous Integration system such as Parabuild provides immediate feedback on quality of changes and allows a team practicing Continuous Integration quickly fixing a build breakage. Teams using such systems are confident in the changes they make, so they can move forward fast.

It is not possible without a Continuous Integration system in place. Dismissing such tools, Continuous Integration may cause more problems than bring benefits. Value of frequent check-ins without an automated validation is low at best.

References:

Paul Duval: Continuous Integration is NOT about the CI server

While the number of managed build configurations is low, it is possible to get away with a simple table view of your build statuses like this one:

As the number of builds grows (one of our customers reported over 150 managed builds), monitoring becomes pain in the butt. Fortunately, Parabuild provides a neat dashboard for your build statuses. A single page allow for watching up to several hundreds of builds simultaneously, depending on the resolution of your monitor. It also provides quick links to items that may require immediate attention, such as the latest broken build or the build that has been broken longest:

More Parabuild screen shots are availablehere There is also live Parabuild instance running Continuous Integration for open source projects.

While the number of managed build configurations is low, it is possible to get away with a simple table view of your build statuses like this one:

As the number of builds grows (one of our customers reported over 150 managed builds), monitoring becomes pain in the butt. Fortunately, Parabuild provides a neat dashboard for your build statuses. A single page allow for watching up to several hundreds of builds simultaneously, depending on the resolution of your monitor. It also provides quick links to items that may require immediate attention, such as the latest broken build or the build that has been broken longest:

More Parabuild screen shots are availablehere There is also live Parabuild instance running Continuous Integration for open source projects.

Our Parabuild employs many useful open source projects. So I though: "How can we give back?" It has downed on me that that best way would be to set up Continuous Integration and nightly builds for the projects that we use and like. How cool is that - Parabuild builds projects that it is made of!

So, here it comes: a Parabuild instance running integration and nightly builds for over twenty open source projects: JUnit, DBUnit, Hibernate, Ehcahe and many others.

It has been over two months since we added most of the projects. I should say that maintainers do a great job by building and testing changes before submitting them to their version control systems. Builds are green most of the times.

To spice up things, look at these statistics charts and build telemetry for some of them. You can click on the image and it will take you to details page:

Change Rate For Ehcache

 

Build Time For SwingX

See this bump in the beginning - that's the time when we moved Parabuild to a new server. You can see the difference in build speed.

 

Recent Test Statistics For TestNG

 

Build Status Snippets

By the way, it is also possible to embed real-time statuses for builds under Parabuild control into your project pages. These are some examples:

 

 

Regards,

Slava Imeshev

Our Parabuild employs many useful open source projects. So I though: "How can we give back?" It has downed on me that that best way would be to set up Continuous Integration and nightly builds for the projects that we use and like. How cool is that - Parabuild builds projects that it is made of!

So, here it comes: a Parabuild instance running integration and nightly builds for over twenty open source projects: JUnit, DBUnit, Hibernate, Ehcahe and many others.

It has been over two months since we added most of the projects. I should say that maintainers do a great job by building and testing changes before submitting them to their version control systems. Builds are green most of the times.

To spice up things, look at these statistics charts and build telemetry for some of them. You can click on the image and it will take you to details page:

Change Rate For Ehcache

 

Build Time For SwingX

See this bump in the beginning - that's the time when we moved Parabuild to a new server. You can see the difference in build speed.

 

Recent Test Statistics For TestNG

 

Build Status Snippets

By the way, it is also possible to embed real-time statuses for builds under Parabuild control into your project pages. These are some examples:

 

 

Regards,

Slava Imeshev

Us is takes thirty seconds, literally!

Check this out: a real-time recording of a launch of a release build (3.1.5) for our Continuous Integration and software build management server Parabuild. Once launched, the build cleanly builds the code base, creates distribution packages and deploys the release to a high-speed download site.

Another cool thing is that Parabuild builds Parabuild :)

P.S. Yes, this is our actual Parabuild instance.

Us is takes thirty seconds, literally!

Check this out: a real-time recording of a launch of a release build (3.1.5) for our Continuous Integration and software build management server Parabuild. Once launched, the build cleanly builds the code base, creates distribution packages and deploys the release to a high-speed download site.

Another cool thing is that Parabuild builds Parabuild :)

P.S. Yes, this is our actual Parabuild instance.

Artima just covered the release of Parabuild 3.1. It is interesting how Frank Sommers, the cheif editor at Artima, manages to capture the essence of pretty complex things like build automation and management.

Artima is one of the sanest places for a developer to hang at. Check this community out if you haven't done so yet.

Artima just covered the release of Parabuild 3.1. It is interesting how Frank Sommers, the cheif editor at Artima, manages to capture the essence of pretty complex things like build automation and management.

Artima is one of the sanest places for a developer to hang at. Check this community out if you haven't done so yet.

I've just stumbled upon a blog post by another happy Parabuild user:

"...I'm at a new job now, and we wanted to replicate a CI system. We tried a few open source projects, but they were all lacking in several major areas. Yesterday, I downloaded an evaluation for Parabuild. In one afternoon with this product I had accomplished:

- building all of our software products after every change
- scheduling nightly builds of our products off of the last known good change
- notification of failed builds
- history of builds
- change/build/failure correlation

Basically, in one afternoon I hit the 75% mark of functionality that it took us about 2 years to hit. Additionally, Parabuild has some very nice features for facilitating the extra 25%. It can talk to Perforce (right now we are using Subversion). It can talk to Bugzilla. This means that with a little work, we can generate pretty manangement-speak reports with builds, bugs and changes...

For $2500 this is a steal. To be able to validate all builds in one afternoon is really an extraordinary accomplishment.

That's from colinburns.cob entry Continuous Integration.

Then the weblog continues on describing how easy it was to set up remote builds with Parabuild. Apparently they are using multple virtual environments to run builds. Generally builds running in a VM are a bit slower but good hardware easiliy offsets possible slowdown:

"... It gets better. We upgraded to the top license. With this license you can run agents on remote machines and spread the build out so that it?s not all being done on one machine. We now have a machine dedicated to parabuild that just runs the web interface and scheduler. Two other machines (both virtual, BTW, running on a quad xeon system) build the code. One is building the client builds and one is building our service builds."

The blog also mentions that they had some concerns regarding managing large number of builds under Parabuild:

"...I?m starting to add a lot of projects and the display is getting a bit busy. Once we start branching, it?s going to get a little ugly. However, the update to this software supports RSS feeds, so it should be trivial to set up another web page for folks to look at specific projects of interest."

It looks like they used Parabuild 2.0 back then. Parabuild 3.0 addressed this concern by adding an ability to separate builds into easy to navigate display groups. This allows to control number of the builds simultaneously displayed on the build status pages.

There is even more cool stuff coming in Parabuild 3.1. My favorite is parallel builds. Parallel builds give you an ability to run multiple builds synchronously on remote machines. This feature makes Parabuild ideal for multiplatform Continuous Integration and build acceleration.

Thanks for blogging about Parabuild! We are looking forward to hearing more about your experience!

I've just stumbled upon a blog post by another happy Parabuild user:

"...I'm at a new job now, and we wanted to replicate a CI system. We tried a few open source projects, but they were all lacking in several major areas. Yesterday, I downloaded an evaluation for Parabuild. In one afternoon with this product I had accomplished:

- building all of our software products after every change
- scheduling nightly builds of our products off of the last known good change
- notification of failed builds
- history of builds
- change/build/failure correlation

Basically, in one afternoon I hit the 75% mark of functionality that it took us about 2 years to hit. Additionally, Parabuild has some very nice features for facilitating the extra 25%. It can talk to Perforce (right now we are using Subversion). It can talk to Bugzilla. This means that with a little work, we can generate pretty manangement-speak reports with builds, bugs and changes...

For $2500 this is a steal. To be able to validate all builds in one afternoon is really an extraordinary accomplishment.

That's from colinburns.cob entry Continuous Integration.

Then the weblog continues on describing how easy it was to set up remote builds with Parabuild. Apparently they are using multple virtual environments to run builds. Generally builds running in a VM are a bit slower but good hardware easiliy offsets possible slowdown:

"... It gets better. We upgraded to the top license. With this license you can run agents on remote machines and spread the build out so that it?s not all being done on one machine. We now have a machine dedicated to parabuild that just runs the web interface and scheduler. Two other machines (both virtual, BTW, running on a quad xeon system) build the code. One is building the client builds and one is building our service builds."

The blog also mentions that they had some concerns regarding managing large number of builds under Parabuild:

"...I?m starting to add a lot of projects and the display is getting a bit busy. Once we start branching, it?s going to get a little ugly. However, the update to this software supports RSS feeds, so it should be trivial to set up another web page for folks to look at specific projects of interest."

It looks like they used Parabuild 2.0 back then. Parabuild 3.0 addressed this concern by adding an ability to separate builds into easy to navigate display groups. This allows to control number of the builds simultaneously displayed on the build status pages.

There is even more cool stuff coming in Parabuild 3.1. My favorite is parallel builds. Parallel builds give you an ability to run multiple builds synchronously on remote machines. This feature makes Parabuild ideal for multiplatform Continuous Integration and build acceleration.

Thanks for blogging about Parabuild! We are looking forward to hearing more about your experience!

Build breakage patterns are causes of repeatable failures of continuous integration and daily software builds. There are generally two kinds in build breakage patterns: technical and psychological. While material causes of psychological patterns are still technical, and are a subject of a separate discussion, they worth separating into a dedicated category because approaches to avoiding them are very different from the technical ones. It is important to understand that once recognized, software build breakage patterns can be avoided. Reduced build breakage means more efficient and enjoyable software development.

"Five O'clock Check-In" Pattern

I was inspired to write this by amazing statistics that our customers shared with us. Our analysis shows that vast majority of the build failures falls on the end of the day, with factual build breakage time ranging from 5PM to 8PM, depending on the duration of the build.

We call this pattern "Five O'clock Check-In".

As name implies, builds get broken because of check-ins made after five o'clock. Below you can see a histogram that is provided by one of our customers that shows distribution of build failures by hour (this and other statistics is available to Parabuild users). While numbers vary from company to company, this histogram is very characteristic. You can see a clear spike in build breakage at 6PM. You may ask why there is a second one at 2AM. This company has an offshore R&D; at GMT-13 time zone!


Figure 1: Distribution of build failures by hour

This pattern is purely psychological. There is a known tendency to check in changes in the end of the day. At that time engineer's ability to critically assert actions is at its lowest level. This, combined with readiness to go home, produces the main excuse not to run clean build and tests before checking in changes - "It is a small change and it is not going to break anything".

Avoiding Build Breakage Caused by "Five O'clock Check-In" Pattern

Five o'clock check-in pattern contributes to the most of build failures seen in continuous integration builds. But it can be (and is) avoided by establishing a simple, easy to follow policy: No check-ins should be made after 5PM (or whatever your de-facto end of the day is). This alone may reduce build breakage by up to 50%!

Hope this helps.

Regards,

Slava Imeshev

Build breakage patterns are causes of repeatable failures of continuous integration and daily software builds. There are generally two kinds in build breakage patterns: technical and psychological. While material causes of psychological patterns are still technical, and are a subject of a separate discussion, they worth separating into a dedicated category because approaches to avoiding them are very different from the technical ones. It is important to understand that once recognized, software build breakage patterns can be avoided. Reduced build breakage means more efficient and enjoyable software development.

"Five O'clock Check-In" Pattern

I was inspired to write this by amazing statistics that our customers shared with us. Our analysis shows that vast majority of the build failures falls on the end of the day, with factual build breakage time ranging from 5PM to 8PM, depending on the duration of the build.

We call this pattern "Five O'clock Check-In".

As name implies, builds get broken because of check-ins made after five o'clock. Below you can see a histogram that is provided by one of our customers that shows distribution of build failures by hour (this and other statistics is available to Parabuild users). While numbers vary from company to company, this histogram is very characteristic. You can see a clear spike in build breakage at 6PM. You may ask why there is a second one at 2AM. This company has an offshore R&D; at GMT-13 time zone!


Figure 1: Distribution of build failures by hour

This pattern is purely psychological. There is a known tendency to check in changes in the end of the day. At that time engineer's ability to critically assert actions is at its lowest level. This, combined with readiness to go home, produces the main excuse not to run clean build and tests before checking in changes - "It is a small change and it is not going to break anything".

Avoiding Build Breakage Caused by "Five O'clock Check-In" Pattern

Five o'clock check-in pattern contributes to the most of build failures seen in continuous integration builds. But it can be (and is) avoided by establishing a simple, easy to follow policy: No check-ins should be made after 5PM (or whatever your de-facto end of the day is). This alone may reduce build breakage by up to 50%!

Hope this helps.

Regards,

Slava Imeshev

Ever wanted to find a build server that:

- takes 2 minutes to install,
- supports both continuous integration and stable scheduled (AKA QA/daily/nightly) builds,
- runs on multiple platforms in local and remote modes,
- integrates with your version control,
- provides you release notes straight from your bug tracking system,
- has a neat web UI and is a pleasure to use,
- has a searchable archive of build results, logs and change lists,
- doesn't require throwing away you precious make/ant/msbuild/maven/nant/shell scripts,
- just works?

You got it - Viewtier Systems just opened an early access program for its automated build management server Parabuild. Join in - Viewtier offers free licenses for bugs found!

Parabuild home page:
http://www.viewtier.com/products/parabuild/index.htm

Parabuild EAP:
http://www.viewtier.com/products/parabuild/eap.htm

Hope this helps.

Regards, Slava Imeshev
Tired of your job? Need to hire developers? Visit DZone Jobs: great people, great opportunities.

Ever wanted to find a build server that:

- takes 2 minutes to install,
- supports both continuous integration and stable scheduled (AKA QA/daily/nightly) builds,
- runs on multiple platforms in local and remote modes,
- integrates with your version control,
- provides you release notes straight from your bug tracking system,
- has a neat web UI and is a pleasure to use,
- has a searchable archive of build results, logs and change lists,
- doesn't require throwing away you precious make/ant/msbuild/maven/nant/shell scripts,
- just works?

You got it - Viewtier Systems just opened an early access program for its automated build management server Parabuild. Join in - Viewtier offers free licenses for bugs found!

Parabuild home page:
http://www.viewtier.com/products/parabuild/index.htm

Parabuild EAP:
http://www.viewtier.com/products/parabuild/eap.htm

Hope this helps.

Regards, Slava Imeshev