testingReflections.com - Continuous Integration

Build Blindness

Sun, 27 Aug 2006 12:59:01 +0100

[textile]I call this phenomenon "Build Blindness":

Unfortunately, if the red light is already on, we tend to ignore all the symptoms of a broken build because, after all, it's already broken. If the red light is on for more than an hour, build-is-broken becomes the natural state of affairs. from Agitar's Build Failures Policy on DeveloperTesting.com

I was inspired by the usability phenomenon of "banner blindness":http://en.wikipedia.org/wiki/Banner_blindness. Although different in many ways, Build Blindness can also result from a form of conditioning. The longer the build stays red, the less likely you will notice it's red. Agitar's policy document addresses this by suggesting specific steps to getting it green again, even if it requires a necessary compromise. One company I visited a while back had red builds that spanned weeks. No one seemed to notice (or be bothered) that it was red after while... it became the norm. This is something to avoid and I generally recommend positive reinforcement through monthly awards for the person with the lowest broken-build to check-in ratio and "fastest fixer" to avoid this (or turn it around). A leaderboard can be shown/commented on at the end of the daily stand-up... but just for a little fun... I wouldn't recommend using it as a stick to hit people with.

Risk-based continuous integration: testing as project risk.

Tue, 09 May 2006 09:42:15 +0100

I’m going to invent a new term “Risk-based continuous integration” am I? I believe that practice is not so widely used, or at least not formalized. I hope to hear from You if anyone openly practice something similar. Any comments, argues and even attacks are also welcome. I plan to blog technical details of the practice, but hope to receive some feedback to understand level of detailed I should provide. Meanwhile I will try to describe the term in general.

QuickBuild: cross-platform build automation and management server

Thu, 16 Feb 2006 08:58:53 +0000

QuickBuild is a cross-platform build automation and management server which helps continuous integration or nightly builds. Besides the ability to automate your builds, QuickBuild puts extra emphasis on build management so that your QA/release builds can be generated and managed in a simple and efficient way. Configuration, monitoring, and access to build artifacts are all done through an intuitive web interface. Your development and testing team will have a central area to access the build information.

QuickBuild

Tue, 14 Feb 2006 12:00:40 +0000

PMEase announces the release of QuickBuild 1.0, the professional version of the open source build server, Luntbuild. Besides being a decent build automation and continuous integration server, it puts extra emphasis on build management. Some feature highlights:

1. Powerful but easy to use interface. QuickBuild's web interface has been greatly improved compared to Luntbuild. You are able to control behavior of QuickBuild through OGNL expression. Typical OGNL expressions are predefined, and you only need to choose proper expression from a context sensitive menu.

Template Projects with CruiseControl 2.4

Sat, 11 Feb 2006 09:34:57 +0000

At the end of January CruiseControl 2.4 was released. Among all the new features and bug fixes one of the most interesting to me is the idea of using plugin preconfiguration to create template projects. By coincidence over the last few weeks Kevin has been doing major surgery on our build system to make everything more standardized and logical, so it turned out to be a good time for us to try out this template project idea of ourselves.

Read the full blog entry

Testing VS development progress: different languages?

Fri, 09 Dec 2005 16:15:58 +0000

The issue of test progress invisibility is one that I'm battling with for several years. This time I will point out absence of the specific practices (two of them) that I believe become necessary in the light of multi-layer architectures and agile development methodologies (iterative life-cycle).
I don't have a goal to suggest the best solution, only to demonstrate that we probably need to solve that.

CruiseControl Monitor plugin for FireFox

Mon, 04 Jul 2005 07:01:36 +0100

Monitor your CruiseControl buld status in the Firefox status bar.

Expert .NET Delivery Using NAnt and CruiseControl.NET

Mon, 04 Jul 2005 07:02:36 +0100

At first glance, building and deploying applications seem simple enough. But in fact, difficult releases without any confidence or processes backing them are very common. Integration and management of a new deployment can be laborious and fraught with risk. So as team size and volume of projects grow, management becomes more difficult and risk more pronounced. This book is a guide to the implementation of good processes in a .NET environment. Author Marc Holmes focuses on actual implementation, and details patterns and anti-patterns to watch out for. He also provides a practical and in-depth look at NAnt and CruiseControl.NET, and solutions to common problem scenarios.

Continuous Integration & .NET (2): Continuous Integration and beyond...

Thu, 19 May 2005 06:37:55 +0100

While unfamiliar to many developers, Continuous Integration is not a new concept at Microsoft, as is evident by Steve McConnell's observation. Consequently, in this second installment of a two-part article, I examine the setup of a version-control system and configuration of a Continuous Integration tool that runs off of the version-control system in the .NET environment. I then integrate these tools into the build process to test for conformance with the Microsoft .NET Framework Design Guidelines, and finally address the issue of code-coverage testing.

Continuous Integration & .NET (1): Weaving together an open-source solution

Thu, 19 May 2005 06:38:53 +0100

Several basic tools used to support Continuous Integration were ported to the .NET environment during the 1.0 release of the Framework. Other tools, such as CruiseControl and Clover, have been ported more recently. Furthermore, certain other tools such as NDoc are indigenous to .NET and only conceptually related to their Java counterparts (Java Doc, in this case). For the most part, articles written to date about these tools have addressed only a subset of the tools (usually NAnt and NUnit), thus failing to weave together a holistic Continuous Integration solution. Moreover, the unit-testing examples are function based and fail to address the database-driven reality of today's enterprise applications.

Automated Tests and Continuous Integration in Game Projects

Tue, 26 Apr 2005 07:27:31 +0100

We were first confronted with the notion of automated testing when, in the year 2000, customers of our back then still very young middleware company complained about stability issues and bugs in our 3D engine. Until that time, we had relied on manual tests performed by the developers after implementing a new feature, and on the reports of our internal demo writers who were using these features to create technology demos for marketing purposes. After thoroughly analyzing the situation, we came to the conclusion that our quality problems were mostly related to the way we were testing our software. [..]

Hudson: continuous integration build system

Mon, 14 Feb 2005 06:21:45 +0000

Hudson monitors executions of repeated jobs, such as building a software project or jobs run by cron. It builds software projects continuously, providing an easy-to-use build system that makes it easier for developers to integrate changes to the project, and for users to obtain a fresh build. The automated, continoues build increases productivity.It monitors executions of externally-run jobs, such as cron jobs and procmail jobs.

Continuum: continuous integration server

Mon, 14 Feb 2005 06:22:46 +0000

Continuum is a continous integration server for building java based projects. Currently it only supports maven 2 projects.

Enterprise Continuous Integration Using Binary Dependencies [PDF]

Fri, 04 Feb 2005 10:45:28 +0000

Continuous Integration (CI) is a well-established practice which allows us as developers to experience fewer development conflicts and achieve rapid feedback on progress. CI by itself though becomes hard to scale as projects get large or have independent deliverables. Enterprise Continuous Integration (ECI) is an extension to CI that helps us regain the benefits of CI when working with separately developed, yet interdependent modules. We show how to develop an ECI process based upon binary dependencies, giving examples using existing .NET tools.

Tinderbox: Continuous Integration Server

Fri, 04 Feb 2005 10:45:37 +0000

Tinderbox is a detective tool. It allows you to see what is happening in the source tree. It shows you who checked in what (by asking Bonsai); what platforms have built successfully; what platforms are broken and exactly how they are broken (the build logs); and the state of the files that made up the build (cvsblame) so you can figure out who broke the build, so you can do the most important thin