Distributed CI is the present

Leave a comment

I’ve seen recently, lot of posts, articles, saying distributed CI is the future. Sorry guys, it’s the present.

When we look at evolution of tools, techniques, requirement, we saw the distributed tools having lot of success ? So, does build-master over design their build framework ? or do they already work distributed ?

In this article I’ll summarize why I think the CI is already distributed.

What’s distributed today ?

  • Teams … yep,  collocated team, became more and more uncommon. Industry requirements, specific knowledge make collocation of brains more and more difficult, even for Giant ….
  • Source Repository, as soon as your team is distributed, you need to distribute your source repository.  Of course, network speed, huge servers may give you the feeling you don’t need distributed source repository. But do you have really distributed administration ? does the team really use the power of your source repository ? Do you use pre/post build event ? how often they commit ?
  • Dependencies … of course if the team are not co-located, your build process should be able to generate a partially your application, and download up-to-date (or the version you want)  of required libraries. So shared directory, and this kind of stupid stuff, are difficult to sync across the world.  Java community have understand that with artifacts repository that you can setup in your enterprise. Indeed, some language, provide similar functionality (perl,php,ruby, python, …) but how difficult it is to setup a proxy/mirror locally (to have the process under control).
  • The build process, should allow dynamic download of dependencies. Does European, US, Indian, will download dependencies at the same location of course not ! Imagine in Visual Studio the ability to define a binaries repository for all your projects ? able to handle binaries not generated by visual ? or artefacts no generated by VS ….
  • The programming languages are more and more different. Once upon a time, project were C or ++,  Borland even Java. Now, some part are in Java, some in PHP, some in Ruby, …..  Even if you have only one programming language (C#as example), you may have to handle different version in your application ( .Net 1.0 up to .Net 4.0 as example). On large project, it’s may not make sens to keep all your libraries to the last level of your programming language. So it’s common today to have at least 3 programming languages, that you want to test on a least 5 major OS ( and if you want to test 32/64b, you double this number)
  • You clients became more and more heterogeneous, and so, you test platform is more and more complex.  If you write an application, you have to test it on at least 5 , 5 major OS, 5 major language, 5 major Web Browser, …. more than 125 combinations. Of course, if you minimized and combined some tests, you have at least  5 tests  platforms.
  • The two previous point, encourage the continuous integration framework to scale easily, and to distribute build on a farm of servers, and that, at the job level. Indeed, all your libraries, applications, doesn’t have the same constraints.
  • Static code analysis, syntax checker. As your team are distributed, don’t have the same knowledge, all your programmers can not follow the same rules at the same time. So, every thing should be configurable by libraries or project.
  • Reporting tools, as all the stuff is distributed, asynchronous, reporting tools should take that into account. Does it make sens to compare code coverage of a new project under ruby, and a legacy one in C ? Does it make sens to compare an experimented team in Java, and a team of beginners ?

So, if your build master take all these elements into account, instead of using centralized tools, you may end with a distrusted platform, allowing team to work at their speed, with their constraints, their knowledge, ….

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.

 

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

Agile Development (Theory in practice) : James Shore and Shane Warden

Leave a comment

During a trip, I’ve read this book.  I think it’s a very good book to start with when you plan to implement agility in your team. Both as a developer or a Product.

Was chatting with a friend of mine some days ago, on the ‘where to start’. Indeed it’s difficult. You may be frighten to introduced agility as a whole, but it’s the best solution. Remove all your usages, challenge your team.  But this required both a highly motivated team, and a good Agile/Scrum practitioner to ask for help on a regular basis.

So, I’ll try why I love the book :

  • Reminder of the agile manifesto … most of the team who plan to move to agile, have read it one day … but it’s a good reminder 🙂
  • The book addressed different aspect of agility : developers, scrum master (scrum method), product, client ….  I’ve seen several team forgetting to quickly that one of the objectives of Agility is to make product and end-user happy. It’s not only about making developers happy.

Among the key tips & trap I’ve  read  in the book :

  • Stories : Ensure the team share the product vision, challenge your stories by asking : what’s the value for the customer … I especially love the challenge card game. One card, one idea challenge the feature….  Product should define MMF (minimal marketable feature). During TShirt sizing, product and developers should challenge each other, if product requires a feature complex to implement, sometime he will be happy with an ersatz of the feature, but easy to do. The product should also define, how to test the feature.
  • Sprint planning :  the team (or a team member) should have prepare the sprint planning, he should have understand what the product want, and anticipate most of the technical issues. Define the success criteria of your sprint.
  • Estimate : time give you idea on how you did mistake on estimation … a team will all the time estimate the same way… (same X% error)
  • Sprint :  remove task as soon as possible (if you have some delay), it will help team working on the most priority one, and will involve product on definition of the new priorities.
  • Demo : don’t lie … if your demo don’t work, be honest .. don’t hide something … elsewhere next sprint, or the “Go live” will be a disaster …

Release process:

  • Each release made by a different person, should be part of the sprint, as at the end of the sprint you should be able to go live …

Pair programming , the magic solution ?

Leave a comment

After several year of watching/reviewing agile project, I’m wondering what make a project a success or a massive failure.
First, to clarify my definition of success is : the team has delivered what the product and/or the end user was expected in a timely way. With this definition, i removed the aspect of a product team not delivering what the end user expect 🙂 that’s occur … sometime … often … 🙂
So, assuming you have a group of 7-10 engineers, what make a project a success or a failure :

Success key :

  • team spirit : everyone is happy to help each team members
  • task sharing : everyone in the team can take every task
  • release : everyone can release the project
  • bugs : everyone works on bugs
  • refactoring : everyone re-factor the code, enhance it
  • Code quality is the first priority of the eng. team
  • Delivering backlog item is the second one.

Failure Keys :

  • each task can be take by only one or two guys
  • Delivering poor quality backlog item, requiring post sprint refactoring … never done in the real life … so increasing the technical debt.
  • Having several backlog : one for the product team, one for the technical stuff … We are delivering software, so technical issue is part of the product.
  • Team changing often … introducing a new person is the team, is not so easy, as the team is working as one guy, it’s may be difficult to be part of it.

That still a list under progress, but from my experience, the two keys for success are :

  • Good communication among engineer and product team
  • Good team work, and in this context, pair programming seems to me the best way to achieve most of the engineering requirement with one practice.

Indeed, by doing extreme pair programing, even team programming is a easy way to achieve all the success point.
Let me explain a bit. What i call extreme pair programming is a pair programing practice were :

  • you change the pair often (at least once a day)
  • as soon as you need an expert point of view, change the pair, to get the help you need
  • as soon as you are block, change the pair, explaining your problem to a new comer, often unblock you.
  • when you need to define a new team practice, take a projector, all the team looking at the screen, only one keyboard … and do an time boxes open discussion to present the benefits of the practice …
  • change keyboard often … may be one developer write the test, and the other one write the code ….
  • you wrote faster code : development is not writing text in a code source file … you have to think, analyze, design, test … So, two brain for one keyboard is not a waste of time
  • Do not interrupt the code writer too often, you have to think about design issue, code enhancement … you don’t have time to focus on typos.

So as a conclusion, may be one of the first development practices to put in place is pair programming for the success of your project.

L’alchimiste Agile

2 Comments

Des envies de Noël ? Vous avez envis de vous prendre pour un Père Noël, un elfe, un renne , …..

je vous encourage a lire, essayer, expérimenter l’alchimiste Agile.

Hier, (grâce à l’absence d’Alex … :-D), j’ai eu l’occasion, au sein du CARA , de pratiquer les rétrospectives sous un angle nouveau.

Déguisé en père Noël, Emmanuel nous à fait réfléchir à comment améliorer notre ligne de fabrication de jouets …. Sans vouloir tout décrire, je vous encourage à lire le blog de nos amis suisses, ainsi que d’approfondir la méthode des 5 pourquoi, qui permet, a mon humble avis, de se rapprocher de la cause du problème.

Older Entries