Distributed CI

First benefit of my new twitter account, i’ve discovered this blog (http://qualityswdev.com/) . Seems interesting to go deeper in the reading.

I’m not the only one in the world that belived that’s the mandatory next step !

3/8 Mister build define is battle plan

Mr Build wonder how to start to solve its issues. He knows, several path are possible.
He know his goal : have a perfect build …. but hesitate with the path too choose.

So, first of all, defined the priority of the issues. Mister Build, organize/prioritize the issue as :

1. Does compiling trunk and a branch at the same time on the computer lead to a random result ? yep … i try it … and discover some tests not able to run in parallel … In his mind mister build expect to be able to mount a second build box in parallel.
2. Do you have a problem if your build server is down ? yes, even if I did a standard installation, lot of plugin, lot of configuration file to recreate … In is mind, mister build expect to mount / automatize the creation of the second box.
3. Does changing your source code repository will cost you some (too much) money ? yep … too many location for configuration, some (too much) of the build configuration information are defined on the CI scheduler … Too far away to have a clean vision
4. Do you need to change your setup generation, each time you change a dependencies ? yep, even if setup package collect automatically all sub dependencies, i need a manual step to put them in the setup configuration file. Too far away to have a clean vision

So, we have a list of issues, a battle plan … so let solve the issues.

Mister build got his first car ! he’s level One

Agile Grenoble : Le programme est la !!!

http://agile-grenoble.org/programme

1/8 Mister Build has problems

Mister build is part of a team, having some issues on its project. It was difficult for him to name/qualify its issues, so he decided to define a smell list.

Bad Smell list for a build

Not Automated

1. Do you have a problem if   your build server is down ?
2. Do you use a build script different for the developers boxes  ?
3. Does your build is working on some computers but not on the other ones ?

Not Deterministic

1. Do you have some resources not packaged in your application ?
2. Does building twice the same code version, with the same inputs, produce a different result  (version number, … ) ?
3. Do you use a build script different for the release ?
4. Does your build ran on two computers produce something slightly different ?

Not Scalable

1. Does compiling two libraries at the same time on the computer, lead to a failing build ?
2. Does compiling trunk and a branch at the same time on the computer lead to a random result ?

Not Simple

1. Does your setup is difficult to maintain ?
2. Do you have some developers not able to update the build mechanism ?

Highly Coupled

1. Does changing your source code repository will cost you some (too much) money ?
2. Does changing your binary storage will cost you some (too much) money ?
3. Do you have conflicts between your IDE and your build process ?

Bad Execution time

1. Does your tests run time is too long ?
2. Does the build take too much time ?
3. Does your build time take time because you need to package for several environment ?
4. Does your build time is linked to the number of environment you deploy on ?
5. Does your build time is linked to the number of  language of your application ?
6. Does your application used several programming languages, and you don’t know how to link them ?

Bad Dependencies management

1. For some libraries included, do you have no clue where they come from ?
2. Do you have a library , you don’t know the version ?
3. Does your configuration files are included in your libraries ?
4. Does some dependencies among your modules are out of control ?
5. Is there any transitives dependencies you don’t know ?
6. Do you need to change your setup generation, each time you change a dependencies ?

Not Helpful

1. Does your code contains some bugs ?
2. Do you have a developer not using the same coding practices than the rest of the team ?
3. Do you have a developer not using the same coding standard than the rest of the team ?
4. Do you have a developer frightening of doing refactoring ?
5. Do you have a developer who don’t know (don’t have a vision of) the quality of the code he work on ?

If you answered yes, to one of this question, you have a problem like Mister build. In the next posts we’ll see how a simple and automated build process, following less coupling rules, coupled with a continuous integration framework can help you.

As mister build answered yes to some of the questions … he will stay as a pedestrian for some more days …