December 22, 2010
Agility, Continuous Integration, XP
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, ….
November 12, 2010
Un petit post pour faire un petit peu de pub pour la track technique. Un groupe d’informaticien, un peu fou, trouvait que les rencontres agiles manquaient de contenu techniques pour la mise en œuvre dans les équipes des concepts Agile. L’extrem programing apporte quelques réponses, mais la mise en œuvre concrète de Scrum, Kanban, pose ou impose quelques pratique aux équipes de développement.
Citons par exemple, la présence de démos régulière qui impose aux équipes de maitriser complètement leur processus de compilation/ déploiement et de configuration.
Nous avons donc décidé de présenter, non pas une session, mais 4 sessions, avec pour objectif de couvrir tous les aspects de la mise en place technique de l’agilité dans une équipe. Cerise sur le gâteau, nous avons essayer que chacune des sessions puisse se suivre indépendamment. Etant un peu fou, je me suis lancé dans 2 sessions.
- Build et Intégration Continue : nous essayerons de présenter les pratiques pour maitriser et tirer profit de ces outils.
- Déploiement et configuration : que serait l’intégration continue sans déploiement automatique de l’application ? une voiture sans volant ? un vase sans fleur ? un bébé sans couche (lavable of course:) ? Nous présenterons donc les bonnes pratiques pour éviter de nombreux murs.
Tout cela évidement, en l’illustrant sur une application avec une base de donnée, des web services et un petit client. En évitant la facilité du monde linux, en faisant tourner cela sous windows.
Les principes vus au cours de ses séances s’applique a tous les langages, toutes les applications et tous les OS. Soyons fou !
Pour faire un peu de pub a nos camarades TDD et BBD sur du legacy, que serait une application qui compile, s’installe mais qui ne marche pas ou qui ne répond pas aux besoins des utilisateurs .
October 15, 2010
Agility, Continuous Integration, Deployment, Tools, XP
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.
Mister build got his first car ! he’s level One
October 14, 2010
Agility, Continuous Integration, Tools, XP
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.