Continuous Integration, an alternative for OpenOffice.org ?

Some time ago I stumbled across an article about continuous integration (http://martinfowler.com/articles/continuousIntegration.html) and that this now had become a mainstream technique for software development. Been there, done that was the first thought. In ancient times of OpenOffice.org development we already had that model: we maintained a single source repository and everyone commits every day. The result was not as good as desired. During heavy refactoring of the code for new big features we ran regularly in the situation that the active development code line was broken. Broken means the source code built fine but the product itself had major bugs that made QA difficult or impossible. That why the concept of child workspaces has been invented (also know as private workspace, private system build and private versioning in SCM pattern language (http://www.scmpatterns.com/book/pattern-summary.html ). With this concept we were able to do complex feature development on private branch and keeping it in sync with the latest changes on the development codeline. There we some child workspaces living for three years before finally integrated, e.g. aw024, aw033).

But although in child workspaces verifications builds and automated tests are done there are still bugs which will be found by manual testing. One have too find the balance between running (and extend the test cases) the test suite for longer time and integrate early into the development code line to enable a broader group of testers for giving feedback.

current integration model

With the current integration model we're doing 0.5 up to 3 builds a week. So isn't this already something like continuous integration ? There's one problem with it: In theory, once you have updated your branch (cws) to the HEAD of the development codeline there are no conflicts to resolve when merging then those changes back, it would be possible to automate this step. Since a OpenOffice.org build for all the languages and platforms will typically last more than 1 day it has become practice that a whole bunch of cws get integrated before the next full build is started. Thankfully the Release Engineering takes care of the integrations then by sequentializing them and coordinate with the developers about potential conflict resolution. This leads to the situation that it can take several days the a build of the integrated child workspace finally is available. I'm not sure if this is a problem at all but I started to wonder about drawing a picture that would like more continuous integration.

I finally got this picture:

sequential integration

The assumption in this picture is that it is possible to do a minimal verifications of the build significantly faster than within a day, e.g. by reducing the build configuration, less languages, less platforms, reduced feature set. If it would be possible to do several builds a day in this way, this would be the possibility to resync their branch to the latest know buildable HEAD of the development codeline. Integration in to HEAD and also the revert back in case of breaking the stuff should then be doable by pure machine power without human interaction. Once a day a farm of build machines would be able to provide a nightly build which could be the basis for manual and automated testing:

nightly builds

I'm not sure if this picture make a big difference and if it is practical at all. At least this would look like more continuous integration, I'm interested in how about others think about it.

Kommentare:

Thx.

Gesendet von muhabbet am März 15, 2009 at 06:54 PM MEZ #

How should this increase the quality of the product?
You will have more Master build, who should tests all that nightly builds?
The bugs will not be integrated because of the build cycle. The bug is integrated because the developer write broken code (perhaps because dependencies to other modules wasn't known) and the QA person did not found the bug before integration. So why the build cycle can increase the quality of a CWS?

Gesendet von Thorsten Ziehm am März 16, 2009 at 06:31 AM MEZ #

Thorsten, I don't think that this is a plan to improve the overall product quality of each milestone. This still is a matter of writing better code and doing better testing.

But what Martin described here is an attempt to fix problems in the way we are doing our builds and to automate the whole process of CWS integration. See also my blog in GullFOSS about the same matter:

http://blogs.sun.com/GullFOSS/entry/continuous_integration_is_it_possible

Of course it should have an indirect influence on the product quality, as fast and reliable integrations will help everybody and will free resources for more productive work.

Gesendet von Mathias Bauer am März 16, 2009 at 11:14 AM MEZ #

Senden Sie einen Kommentar:
Kommentare sind ausgeschaltet.
About

Martin Hollmichel

Search

Archives
« April 2014
MoDiMiDoFrSaSo
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Heute