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 :

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.

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.

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

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.

Rate this:

Mister build try to answers the question of the previous post … and discovered some limits to his build process

It’s current limits are :

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 …

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 …

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 …

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

Hopfully no so bad 🙂 In the next post, I’ll describe mister build battle plan to address these problems.

Does changing your binary storage will cost you some (too much) money ?

Do you have conflicts between your IDE and your build process ?

Bad Execution time

Does your tests run time is too long ?

Does the build take too much time ?

Does your build time take time because you need to package for several environment ?

Does your build time is linked to the number of environment you deploy on ?

Does your build time is linked to the number of language of your application ?

Does your application used several programming languages, and you don’t know how to link them ?

Bad Dependencies management

For some libraries included, do you have no clue where they come from ?

Do you have a library , you don’t know the version ?

Does your configuration files are included in your libraries ?

Does some dependencies among your modules are out of control ?

Is there any transitives dependencies you don’t know ?

Do you need to change your setup generation, each time you change a dependencies ?

Not Helpful

Does your code contains some bugs ?

Do you have a developer not using the same coding practices than the rest of the team ?

Do you have a developer not using the same coding standard than the rest of the team ?

Do you have a developer frightening of doing refactoring ?

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 …

Why not keeping the principle of less coupling to build/CI/static code analysis tools ????

Doing dcode is important, but application design should not be forget.

2) the second point, is some comments : it’s expensive to fix issues …

How can someone justify that fixing an issues at developing time … 5 .. 10 minutes … is more expensive that discovering the issue in production (something like 1$ a minute ? ) , requiring some dev again, some QA, some deployment …..

Of course, the bug may never be seen in production …. for how long ? Don’t forget the Murphy law : if you can have a problem, you’ll have it !