Présentation de Karl Métivier de CGI à l'Agile Tour 2009 Québec

1. Agenda
-----------------------
Introduction
Qu’est-ce que l’intégration continue?
Pourquoi utiliser un processus d’intégration continue?
Qu’est-ce qu’un « Build » réussi?
Outils
Configuration logiciel (SCM)
Tests unitaires
Compilation et gestion de la compilation
Exemple processus
Automatisation des tests fonctionnels
Développement
Métriques
Démonstration
Qu’est-ce qui a bien marché
Les pratiques
Conclusion
Références
1

2. Source:
http://fr.wikipedia.org/wiki/Int%C3%A9gration_continue
Origine:
http://martinfowler.com/articles/continuousIntegration.html
Martin Fowler
Chief Architect at ThoughtWorks
Author of numerous books, including Refactoring & Planning Extreme Programming
With Kent Beck, one of the first people to publish on the subject of CI
Understanding the Approach
In general, continuous integration is the process when code is checked in and is immediately built in the integration stream to see if it
can build with existing code. If the build is successful, then an automated set of tests are run to validate the changes. Once the build
and test are successfully completed, the results are made available to the rest of the developers. The premise is that when you
continuously integrate, you can continually encounter and overcome small manageable integration issues during development avoiding
large time-consuming integration issues.
Consideration should be given to whether a continuous integration approach is right for you. Most projects these days operate in the
classical integration approach where changes are not frequently made, the changes may be quite large and include changes in
numerous files, and other developers do not have to use these changes until they are ready. The continuous integration approach
applies the changes to the public very frequently, the changes are typically small and precise (change only what exactly needs to be
changed) where one or few files are changed, and the developers must be ready to accept the changes after they have been
successfully built and tested.
Effectively, the continuous integration approach is a cultural shift for many developers who, following the classical approach model, like
to work securely in their static workspace and not have to consider other changes until they are ready for them. The issue with the
classic is that the changes from developers are not applied very frequently, therefore integration (e.g., merging) may become a
significant and often painful effort. The continuous integration approach reduces the significant integration effort, but requires a
different development methodology whereby developers are working on smaller change requests and change sets which require less
time to complete. With all of this in mind, how would a group change from the classical approach to the continuous integration
approach?
In order to start applying the continuous integration approach, consideration should be given to what needs to be in place to make this
happen. First, there must be a development methodology in place to support this new concept. Second, there must an infrastructure in
place that can support the continuous integration approach
2

3. Pour appliquer cette technique, il faut d'abord que :
• le code source soit partagé (en utilisant des logiciels de gestion de versions
tels que VSTS, SourceSafe, CVS ou Subversion) ;
• les développeurs intègrent (commit) quotidiennement (au moins) leurs
modifications ;
• des tests d'intégration soient développés pour valider l'application (avec JUnit
ou NUnit par exemple).
• Ensuite, il faut un outil d'intégration continue tel que CruiseControl, Final
Builder, Team City ou Hudson.
Les pratiques sont les suivantes :
• maintenir un dépôt unique de code source versionné ;
• automatiser les compilations ;
• rendre les compilations auto-testantes ;
• tout le monde committe tous les jours ;
• tout commit doit compiler le tronc sur une machine d'intégration ;
• maintenir une compilation courte ;
• tester dans un environnement de production cloné ;
• rendre disponible facilement le dernier exécutable ;
• tout le monde doit voir ce qui se passe ;
• automatiser le déploiement.
3

4. Tout ce que ça demande, c’est une certaine dose de discipline.
Cela prend beaucoup d’énergie pour l’introduire dans un projet, surtout si
celui-ci est bien avancé.
Mais une fois installé, l’effort de maintenance est minime.
4

5. Pourquoi on fait cela ?
• Pour éviter les intégration pénibles ou le “integration hell”
• Réduire le risque dans un projet
• Tester souvent et régulièrement
• Visibilité
• Éliminer le gaspillage (un des principes du Lean Software Development)
“Integration hell” is the period between code complete and getting a fully integrated
build out the door.
If something hurts…
Exercise – If you’re out of breath after climbing a flight of stairs, quit taking the
elevator and climb more stairs. Soon, you’ll be breathing normally.
Integration Hell – If you spend weeks or months integrating features written by
different teams or even different people on the same team, you’re not integrating
frequently enough. The more you do it, the less it will hurt.
Risk is reduced when you shorten the time between integrations
The more time between integrations
The more change will need to be integrated
The harder the integration
The harder it will be to predict how long it will take
Visibility is increased rapidly with CI
Everyone knows the status of the build
Everyone knows when the build breaks
5

6. Exemple d’une mise en production…
Est-ce que vous avez déjà vécu une simple mise en production qui devait se
terminer en 1-2 heure mais qui a nécessité plutôt 6 heures ?
Que dire quand des moment où quand quelqu’un intègre (enfin) son code et
que la compilation est brisé pendant toute la journée ?
Maintenant, je ne m’en fais plus et j’adore mon serveur d’intégration continue !
6

7. Jouer défensif
• Maximise notre investissement
• Réduit le risque
• Augmentation de la visibilité
L’intégration continue règle certains problèmes
Augmente le niveau de confiance de l’équipe
Les problèmes se manifestent généralement le même jour qu’ils ont été
introduits.
Les changements qui ont pu introduire le problème étant plus limités, le
problème peut plus facilement être corrigé.
Un build fiable est toujours disponible
Résultat - Productivité accrue en réduisant le temps à chercher les
causes de problème
• Les principaux avantages d'une telle technique de développement sont :
• les problèmes d'intégration sont détectés et réparés de façon continue,
évitant les problèmes de dernière minute ;
• prévient rapidement en cas de code incompatible ou manquant ;
• test immédiat des unités modifiées ;
• une version est toujours disponible pour test, démonstration ou distribution.
• On peut aussi implanter un déploiement automatique
7

8. Un bon build d’intégration continue est plus qu’un simple fichier de solution…
Plus l’application est complexe, plus l’automatisation prend son sens
« Builder » seulement ce qui a changé
Souvent plus simple de tout « Rebuilder »
If you're writing a small program with a dozen or so files, then building the application may be just a matter of a single
command to a compiler: javac *.java. Bigger projects need rather more. In these cases you have files in many
directories. You need to ensure the resulting object code is in the proper place. As well as compilations there may be
link steps. You have code generated from other files that needs to be generated before you can compile. Tests need
to be run automatically.
A big build often takes time, you don't want to do all of these steps if you've only made a small change. So a good
build tool analyzes what needs to be changed as part of the process. The common way to do this is to check the
dates of the source and object files and only compile if the source date is later. Dependencies then get tricky: if one
object file changes those that depend on it may also need to be rebuilt. Compilers may handle this kind of thing, or
they may not.
Depending on what you need, you may need different kinds of things to be built. You can build a system with or
without test code, or with different sets of tests. Some components can be built stand-alone. A build script should
allow you to build alternative targets for different cases.
Once you get past a simple command line, scripts often handle the load. These might be shell scripts or use a more
sophisticated scripting language such as perl or python. But soon it makes sense to use an environment designed for
this kind of thing, such as the make tools in Unix.
In our Java development we quickly discovered we needed a more serious solution. Indeed Matt put a good bit of
time into developing a build tool called Jinx which was designed for Enterprise Java work. Recently, however, we
have switched over to the open-source build tool Ant. Ant has a very similar design to Jinx, allowing us to compile
Java files and package them into Jars. It also makes it easy for us to write our own extensions to Ant to allow us to
do other tasks within the build.
Many of us use IDEs, and most IDEs have some kind of build management process within them. However these files
are always proprietary to the IDE and often fragile. Furthermore they need the IDE to work. IDE users set up their
own project files and use them for individual development. However we rely on Ant for main builds and the master
build is run on a server using Ant.
8

9. CC et CC.Net:
•CI server built on .NET
•Support for multiple source code repositories, including TFS
•Extensible XML based configuration
•Executes NAnt and MSBuild projects
•Web-based dashboard
•System tray based notifications
Team Foundation Server:
•Fully featured CI server built on .NET
•Executes MSBuild projects or Java Projects
•VSTS shell based interface
•Integrated with TFS data warehouse for reporting
•Built in drop management
•Power Tools
•System tray applet
•Vista sidebar support
•DevEnv.exe custom task
Final Builder :
• Interface graphique facile à utiliser (pas de XML)
• Plusieurs types d’actions prédéfinies
• Création de script de type workflow avec des try/catch, if then et des break points
• Log détaillé
• Variables, scripts
Others:
•Hudson
•TeamCity
•Cruise
•…
9

10. Outils obligatoires ou les « Must have » :
Outils de contrôle de code source (SCM)
•CVS
•Subversion
•ClearCase
•Visual SourceSafe
•Team Foundation
Outils de « Build »
•Ant
•NAnt
•FinalBuilder
•MSBuild
Outils d’automatisation
•CruiseControl
•CruiseControl.NET
•FinalBuilder
•…
Outils que l’on devrait avoir ou « Nice to have » :
Outils de tests unitaires
•xUnit
•Test Driven .NET
Outils de déploiments
•Nullsoft Scriptable Install System (NSIS)
•Wix
•Wise
•Install Shield
•Vdproj + msbuild
Revue de codes
•DevPartner
•CheckStyle
•TeamSuite
•Éviter FxCop idéalement…
Aussi, il faut voir avec l’infrastructure de développement actuellement en place et les outils déjà disponible.

11. Habituellement, le gestionnaire de code source et le serveur d’intégration
continue sont sur des machines différentes.
11

12. http://www.sxc.hu/photo/1175306
Bonne question !
L’intégration continue est un drôle de mélange entre l’installation et le
configuration d’un produit et le connaissance du code et de comment il doit
être compilé.
On ne veut pas d’une seule personne qui soit capable de modifier le script de
build au besoin.
Idéalement, une personne fait l’installation initiale et note bien les étapes. Par
la suite, elle devra communiquer aux autres membres de l’équipe la recette et
les trucs appris. Le but est que plusieurs membres de l’équipe soit à l’aise
avec le serveur CI pour s’assurer qu’il roulera toujours même si une personne
est en vacances
12

13. Version client est utile pour composer notre script de build est le tester.
13

14. Avec la version « Serveur », on peut céduler des scripts selon des triggers
externes. Donc, faire de la vrai intégration continue.
Cela vient avec un portail où l’on peut voir ce qui se passe sur le serveur, voir
les logs et intervenir au besoin.
14

15. L’important est que chaque chiffre de la version soit significatif.
Exemple:
1.1.350.300
Premier = Numéro de release (1)
Deuxième = Numéro de l’itération ou du sprint (1)
Troisième = Jour de l’année (350)
Quatrième = No de version du gestionnaire de code source (300)
15

16. Niveau 1 : Tout le code est compilé
Niveau 2 : Les tests unitaires sont exécutés
Niveau 3 : Étapes supplémentaires
La documentation est générée
Les scripts de BD sont exécutés et validés
Les pages web sont régénérées
L’installshield est construit et validé
Des statistiques sont compilés (code coverage, # de lignes de code, les + gros fichiers)
An important thing to decide is what makes a successful build. It may seem obvious, but it's remarkable how this can
get muddy. Martin once reviewed a project. He asked if the project did a daily build and was answered in the
affirmative. Fortunately Ron Jeffries was there to probe further. He asked the question "what do you do with build
errors?" The response was "we send an e-mail to the relevant person". In fact the project hadn't succeeded in a build
for months. That's not a daily build, that's a daily build attempt.
We are pretty aggressive about what we mean by a successful build.
•All the latest sources are checked out of the configuration management system
•Every file is compiled from scratch
•The resulting object files (Java classes in our case) are linked and deployed for execution (put into jars).
•The system is started and suite of tests (in our case, around 150 test classes) is run against the system.
If all of these steps execute without error or human intervention and every test passes, then we have a successful
build
Most people consider a compile and link to be a build. At the least we think a build should include starting the
application and running some simple tests against it (McConnnell used the term "smoke test": switch it on and see if
smoke comes out). Running a more exhaustive set of tests greatly improves the value of continuous integration, so
we prefer to do that as well.

17. L’intégration occasionnelle peut être un exercice pénible
Niveau 1: Quand buildé son code
Plus l’intervalle est grand, plus l’effort d’intégration l’est aussi
Trucs pour gérer son build
Build au moins une fois par jour. Idéalement à chaque « commit » ou
« check-in » !!!
Build une fois par semaine pour tests moins importants
À chaque semaine, assigner une personne en charge des build break
(polénisation) ou avoir une pratique d’équipe en ce sens.

18. Une compilation réussie n’est pas gage de succès
Avec Agile, 2 catégories d’essais
Unitaires (unit testing)
Acceptations (acceptance testing)
Test-Driven-Development (TDD)
On écrit du code qui teste le code source avant que celui-ci soit écrit
Définition des tests unitaires : Building the code right
Définition des tests fonctionnels: Building the right code
Automatisation:
Pas nécessaire  « Nice to have »
Pas encore au point comme les tests unitaires mais devraient devenir plus mainstream dans les années à venir
Permet de rouler les tests fréquemment et de les utiliser pour les tests de régression (Smoke Test)
Fit/Fitness (Framework for integration Testing), WinRunner, Robot,Sliktest, Marathon
Self-Testing Code
Just getting a program to compile is not enough. While compilers in strongly typed languages can spot many problems, there are too many errors that even a successful compile lets through.
To help track these down we put a lot of emphasis on an automated testing discipline - another practice that's advocated by XP.
XP divides tests into two categories: unit tests and acceptance (also called functional) tests. Unit tests are written by dev elopers and typically test an individual class or small group of
classes. Acceptance tests are usually written by customers or an outside test group (with the help of developers) and test the whole system end-to-end. We use both kinds of test, and
automate both kinds of test as much as possible.
As part of the build we run a suite of tests that we call the "BVT" (Build Verification Tests). All the tests in the BVT must pass in order for us to have a successful build. All of the XP-style unit
tests are in the BVT. As this article is about the build process, we'll mostly talk about the BVT here, just bear in mind tha t there is a second line of testing in addition to what's in the BVT, so
don't judge the whole testing and QA effort by the BVT alone. Indeed our QA group doesn't ever see code unless it's passed the BVT since they only work on working builds.
The basic principle is that when developers are writing code they also write tests for that code. When they complete a task, not just do they check in the production code, they also check in
the tests for that code. Those that follow XP closely use the test first style of programming: you shouldn't write any code u ntil you have a failing test. So if you want to add a new feature to the
system, you first write a test that will only work if the feature is there, then you make that test work.
We write the tests in Java, the same language that we're developing in. This makes writing tests just the same as writing cod e. We use JUnit as the framework for organizing and writing
tests. JUnit is a simple framework that allows you to quickly write tests, organize them into suites, and run suites interactively or in b atch mode. (JUnit is the Java member of the xUnit family -
for which there are versions for almost every language.)
Developers typically run some subset of the unit tests with every compile as they are writing the software. This actually spe eds up the development work since the tests help to find any logic
errors in the code you're working on. Then, rather than debugging, you can look at the changes since you last ran the tests. Those changes should be small and thus it's a lot easier to find the
bug.
Not everyone works strictly in the XP test-first style, but the key benefit comes from writing the tests at the same time. As well as making an individual task go faster, it also builds up the BVT
making it more likely to catch errors. Since the BVT runs several times a day, this means that any problems that the BVT dete cts are easier to find for the same reason: we can look at a small
amount of changed code in order to find the bug. This debugging by looking at the changed code is often much more effective t han debugging by stepping though running code.
Of course you can't count on tests to find everything. As it's often been said: tests don't prove the absence of bugs. Howeve r perfection isn't the only point at which you get payback for a good
BVT. Imperfect tests, run frequently, are much better than perfect tests that are never written at all.
A related question is the issue of developers writing tests on their own code. It's often been said that people should not te st their own code, because it's too easy to overlook errors in your
own work. While this is true, the self-testing process requires a rapid turn-around of tests into the code base. The value of that fast turn-around is greater than the value of separate testers. So
for the BVTs we rely on developer-written tests, but there are separate acceptance tests which are written independently.
Another important part of self-testing is to improve the quality of tests with feedback - a key value of XP. Feedback here comes in the form of bugs that escaped the BVT. The rule here is that
you aren't allowed to fix a bug until you have a failing unit test in the BVT. This way every time you fix a bug, you also ad d a test to ensure it doesn't slip past you again. Furthermore this test
should lead you to think of other tests that need to be written to strengthen the BVT.

19. On est rendu ?
Mesures possibles (plusieurs)
Évaluer notre progrès avec l’intégration continue
22

20. Utile si on implante des tests unitaires automatisés.
23

21. Une ligne par projet ou “assembly”
Vérifier les changements
Voir les tendances afin de se trouver des objectifs d’amélioration.
24

22. On peut aussi ajouter diverses mesures sur la qualité du code
25

23. On veut pas avoir à réparer plein de trucs qui auraient pu être éviter.
Faut entretenir notre code régulièrement
26

24. Ade Miller du groupe PnP de Microsoft a fait l’étude suivante après 100 jours
d’intégration continue.
27

25. L’adoption au début était un peu pénible, mais à la fin, on ne s’en passerait
plus.
Le taux de réussite des compilations s’est constamment améliorer.
Des erreurs de références cycliques ont été trouvés au début du projet et non
à la fin.
L’intégration continue ne règle pas tout les problèmes… Il faut quand même
tester le produit fini.
Reste que c’est difficile de faire que l’équipe effectuent des « commit » au
moins une fois par jour. La pratique d’y aller à petits pas est de mise
idéalement.
28

26. Faire la configuration du serveur d’intégration continue au jour 1
S’assurer que la machine en question répond bien
Mesurer et tester ce qui est important
Se bâtir une défense en profondeur
Ne pas avoir peur de changer nos tests et nos mesures avec le temps (avoir
des métriques qui veulent dire quelque chose, qui permettent à l’équipe de
progresser. Pas de métriques punitives !
Au besoin, faire rouler différentes builds.
29

27. Considérer les avertissements comme des erreurs
Tout le monde s’arrête quand le build est brisé
Si on le brise, on le répare !
On ne fait pas de check-in et partir immédiatement après.
Pratiquer le Test Driven Development
Red, Green, Refactor, Integrate!
On ne fait pas de check-out pendant la nuit
Bref, l’intégration continue est une attitude. Il ne faut pas sombrer dans l’indifférence continue.
On ne doit pas débattre de qui a brisé le build et passer du temps là-dessus.
On peut voir aussi l’intégration continue comme une équipe qui travaille ensemble dans un but
commun. Bref, c’est une pratique humaine !
30

28. Automatiser tout ce qui est possible de l’être
Exécuter le « Build » souvent
Se préoccuper des « Builds » échoués immédiatement (Build break)
Pour commencer, on peut y aller par un build qui est déclenché manuellement.
Par la suite, après quelques essais, on peut commencer l’automatisation sur
un serveur. Le but est vraiment d’y aller à petits pas.

29. Malgré une des paroles du manifeste agile, on a besoin d’outils dans tous les projets Agile
Profitez des plus petits projets pour mettre en place le processus et les outils
Le choix des outils est complémentaire aux processus et méthodologies actuels de l’équipe en
place
Automatiser, la clef du succès
Quelques passages de l’article « Tool for Agility » de Kent Beck :
The Agile Manifesto [Beck et al 2001][1] says, “We value processes and tools, but we value
individuals and interactions more.” Like many attempts to encourage change, this is stated
strongly enough that it is open to misinterpretation.
[1] http://agilemanifesto.org/
Tools have evolved to efficiently support the separate activities of software development. Agile
development, an outgrowth of the nearly-universal drive to ever shorter release cycles,
changes the basis of competition for software tools. Rather than single-activity efficiency, tools
need to support frequent transitions between activities.
Agile development relies on tools, especially when those tools are tuned for a different rhythm
of development.
It’s ridiculous to speak of agile software development without tools. There is so much going on
in an agile project every day, so many formerly-manual steps now repeated on fast-forward,
that appropriate tools is essential.

30. Continuous Integration by Martin Fowler and Matthew Foemmel :
http://www.martinfowler.com/articles/continuousIntegration.html
<Continuous Integration/>
http://www.hanselminutes.com/default.aspx?showID=5
CruiseControl & CruiseControl.NET
http://cruisecontrol.sourceforge.net/
http://confluence.public.thoughtworks.org/display/CCNET/Welcome+to+CruiseControl.NET
FinalBuilder: http://www.finalbuilder.com
Nant : http://nant.sourceforge.net/
Nunit : http://www.nunit.org/
Ncover : http://www.ncover.org
Ndoc : http://ndoc.sourceforge.net/
Test Driven .NET : http://www.testdriven.net
Junit : http://www.junit.org
CheckStyle : http://checkstyle.sourceforge.net/
javaDoc : http://java.sun.com/j2se/javadoc/
Ant : http://ant.apache.org/

31. 34

32. 35

33. 36