3/8 Mister build define is battle plan

Leave a comment

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.

several path

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

07 voiture

2/8 Mister build is caught by the patrol ….

Leave a comment

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

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.

 

Agile Grenoble : Le programme est la !!!

Leave a comment

http://agile-grenoble.org/programme

1/8 Mister Build has problems

1 Comment

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 …

IMG_5135

Code quality

Leave a comment

I’ve not post for some time, i was quite bust to set up some CI / metrics tools on a new project.

This raise me some questions / comments.

1) Complexity of the tools

When you read (even in my posts) it’s simple …  I’ve forget a bit the ‘open community’ and in its bad aspects.

Let me illustrate a bit. I am working in a team using mainly Java / Php.

So, using standard tools :

  • Source revision control : svn
  • IDE : eclipse
  • Build : Maven
  • CI : hudson

So, up to now, everything looks fine. I used to use some static code anlysis, in order to know the code quality :

Jdepend, PMD, findbugs, Javancss, cobertura, sonar, Coverity, …

So, nothing really exotic/fancy and most of them are ‘classical’ static code analysis tools.

So,  doing  my ‘Yoda’ show, i’ve encourage the team to use them as soon as possible in their development process so in the IDE.

I’ve plug them in their pom file (maven configuration file), update my hudson installation to have the trend, ….

AND … you know what …. 6 tools,  16 versions needed, because of incompatibility in maven, hudson,  pmd, ….

1 tool , 4 plugin needed …. most of the time just to parse an XML file, or to draw a simple curve with linear data …..

What’s a mess ! where is simplicity ? easy to use ? why coupling a CI tools with build specific plugin ??? why mixing build tools with Source control tools ???

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 !