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

Source: http://fr.wikipedia.org/wiki/Int%C3%A9gration_continue

Origine:http://martinfowler.com/articles/continuousIntegration.htmlMartin FowlerChief Architect at ThoughtWorksAuthor of numerous books, including Refactoring & Planning Extreme ProgrammingWith Kent Beck, one of the first people to publish on the subject of CI

Understanding the ApproachIn 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

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

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

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 integratedbuild 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 integratingfrequently enough. The more you do it, the less it will hurt.

Risk is reduced when you shorten the time between integrationsThe more time between integrationsThe more change will need to be integratedThe harder the integrationThe harder it will be to predict how long it will take

Visibility is increased rapidly with CIEveryone knows the status of the buildEveryone knows when the build breaks

5

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

Jouer défensif

• Maximise notre investissement• Réduit le risque• Augmentation de la visibilité

L’intégration continue règle certains problèmesAugmente le niveau de confiance de l’équipeLes 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 disponibleRé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

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

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

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.

Habituellement, le gestionnaire de code source et le serveur d’intégration

continue sont sur des machines différentes.

11

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

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

13

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

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

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.

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.

Une compilation réussie n’est pas gage de succèsAvec 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 CodeJust 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 until 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 code. 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 batch 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 speeds 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 detects 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 than 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. However 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 test 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 add 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.

On est rendu ?

Mesures possibles (plusieurs)

Évaluer notre progrès avec l’intégration continue

22

Utile si on implante des tests unitaires automatisés.

23

Une ligne par projet ou “assembly”

Vérifier les changements

Voir les tendances afin de se trouver des objectifs d’amélioration.

24

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

25

On veut pas avoir à réparer plein de trucs qui auraient pu être éviter.

Faut entretenir notre code régulièrement

26

Ade Miller du groupe PnP de Microsoft a fait l’étude suivante après 100 jours

d’intégration continue.

27

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

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

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

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.

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.

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/

34

35

36