SlideShare une entreprise Scribd logo
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
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
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 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
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è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
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è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.
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

Contenu connexe

Tendances

Principes de L'intégration Continue
Principes de L'intégration ContinuePrincipes de L'intégration Continue
Principes de L'intégration ContinueXavier Warzee
 
Devops Introduction au mouvement
Devops Introduction au mouvementDevops Introduction au mouvement
Devops Introduction au mouvement
Ulrich VACHON
 
Intégration continue
Intégration continueIntégration continue
Intégration continueKlee Group
 
Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOps
Microsoft
 
Presentation-DEVOPS-par-GDG
Presentation-DEVOPS-par-GDGPresentation-DEVOPS-par-GDG
Presentation-DEVOPS-par-GDG
TinarivosoaAbaniaina
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisJason De Oliveira
 
Au secours, mon chef m'a demandé de passer au DevOps
Au secours, mon chef m'a demandé de passer au DevOpsAu secours, mon chef m'a demandé de passer au DevOps
Au secours, mon chef m'a demandé de passer au DevOps
antony_guilloteau
 
Afterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiquesAfterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiques
OCTO Technology Suisse
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Sébastien Bourguignon
 
BBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - PuppetBBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - Puppet
Olivier BAZOUD
 
JCertif 2012 : Integration continue avec Jenkins
JCertif 2012 : Integration continue avec JenkinsJCertif 2012 : Integration continue avec Jenkins
JCertif 2012 : Integration continue avec Jenkins
Rossi Oddet
 
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
Henri Gomez
 
Introduction à la démarche Devops
Introduction à la démarche DevopsIntroduction à la démarche Devops
Introduction à la démarche Devops
Romain Chalumeau
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
Bilal ZIANE
 
Journée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOpsJournée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOps
Publicis Sapient Engineering
 
Method XP
Method XP Method XP
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèse
COMPETENSIS
 
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes PratiquesEmmanuel Hugonnet
 
Le DevOps : La clé de la transformation digitale ?
Le DevOps : La clé de la transformation digitale ?Le DevOps : La clé de la transformation digitale ?
Le DevOps : La clé de la transformation digitale ?
Amico Fabien
 
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
Yasmine Amrani
 

Tendances (20)

Principes de L'intégration Continue
Principes de L'intégration ContinuePrincipes de L'intégration Continue
Principes de L'intégration Continue
 
Devops Introduction au mouvement
Devops Introduction au mouvementDevops Introduction au mouvement
Devops Introduction au mouvement
 
Intégration continue
Intégration continueIntégration continue
Intégration continue
 
Introduction à DevOps
Introduction à DevOpsIntroduction à DevOps
Introduction à DevOps
 
Presentation-DEVOPS-par-GDG
Presentation-DEVOPS-par-GDGPresentation-DEVOPS-par-GDG
Presentation-DEVOPS-par-GDG
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
 
Au secours, mon chef m'a demandé de passer au DevOps
Au secours, mon chef m'a demandé de passer au DevOpsAu secours, mon chef m'a demandé de passer au DevOps
Au secours, mon chef m'a demandé de passer au DevOps
 
Afterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiquesAfterwork Devops : vision et pratiques
Afterwork Devops : vision et pratiques
 
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSIAprès l’#agilité, le #DevOps, la nouvelle arme de la DSI
Après l’#agilité, le #DevOps, la nouvelle arme de la DSI
 
BBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - PuppetBBL - TDD pour les DevOps - Puppet
BBL - TDD pour les DevOps - Puppet
 
JCertif 2012 : Integration continue avec Jenkins
JCertif 2012 : Integration continue avec JenkinsJCertif 2012 : Integration continue avec Jenkins
JCertif 2012 : Integration continue avec Jenkins
 
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
DevOps - Retour d’expérience - AlpesJug du 20 Septembre 2011
 
Introduction à la démarche Devops
Introduction à la démarche DevopsIntroduction à la démarche Devops
Introduction à la démarche Devops
 
Extreme programming
Extreme programmingExtreme programming
Extreme programming
 
Journée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOpsJournée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOps
 
Method XP
Method XP Method XP
Method XP
 
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèse
 
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel  - Introduction Et Bonnes PratiquesIndustrialisation Du Logiciel  - Introduction Et Bonnes Pratiques
Industrialisation Du Logiciel - Introduction Et Bonnes Pratiques
 
Le DevOps : La clé de la transformation digitale ?
Le DevOps : La clé de la transformation digitale ?Le DevOps : La clé de la transformation digitale ?
Le DevOps : La clé de la transformation digitale ?
 
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
5- [ASP.NET Core] Devops : VSTS, Git, Azure, Docker, Linux
 

Similaire à Processus d’intégration continue et outils

Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptx
boulonvert
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptx
ZALIMAZA
 
Présentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxPrésentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptx
ZALIMAZA
 
Présentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxPrésentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptx
ZALIMAZA
 
Présentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptxPrésentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptx
ZALIMAZA
 
Présentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptxPrésentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptx
ZALIMAZA
 
Présentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxPrésentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptx
ZALIMAZA
 
Présentation DEVOPSS.pptx
Présentation DEVOPSS.pptxPrésentation DEVOPSS.pptx
Présentation DEVOPSS.pptx
ZALIMAZA
 
Présentation DEVOPS_.pptx
Présentation DEVOPS_.pptxPrésentation DEVOPS_.pptx
Présentation DEVOPS_.pptx
ZALIMAZA
 
Présentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptxPrésentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptx
ZALIMAZA
 
Présentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxPrésentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptx
ssuserf298861
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
neuros
 
At2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicAt2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville Public
Emmanuel Hugonnet
 
devops.pdf
devops.pdfdevops.pdf
devops.pdf
qsdqsd4
 
Rex Software Factories 20140117 - Ensim
Rex Software Factories 20140117 - EnsimRex Software Factories 20140117 - Ensim
Rex Software Factories 20140117 - Ensim
Laurent Broudoux
 
20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven
Arnaud Héritier
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
Sid Ahmed Benkraoua
 
L'integration continue pour tous
L'integration continue pour tousL'integration continue pour tous
L'integration continue pour tous
Aurelien Navarre
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange Labs
Emmanuel Hugonnet
 
NightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous DeliveryNightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous Delivery
Zenika
 

Similaire à Processus d’intégration continue et outils (20)

Présentation DEVOPS.pptx
Présentation DEVOPS.pptxPrésentation DEVOPS.pptx
Présentation DEVOPS.pptx
 
Présentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptxPrésentation DEVOPS_PO.pptx
Présentation DEVOPS_PO.pptx
 
Présentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptxPrésentation DEVOPS_DIR.pptx
Présentation DEVOPS_DIR.pptx
 
Présentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptxPrésentation DEVOPS_CONSOLE.pptx
Présentation DEVOPS_CONSOLE.pptx
 
Présentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptxPrésentation DEVOPS_hyper.pptx
Présentation DEVOPS_hyper.pptx
 
Présentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptxPrésentation DEVOPS_Mauritanie.pptx
Présentation DEVOPS_Mauritanie.pptx
 
Présentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptxPrésentation DEVOPS-Majeur.pptx
Présentation DEVOPS-Majeur.pptx
 
Présentation DEVOPSS.pptx
Présentation DEVOPSS.pptxPrésentation DEVOPSS.pptx
Présentation DEVOPSS.pptx
 
Présentation DEVOPS_.pptx
Présentation DEVOPS_.pptxPrésentation DEVOPS_.pptx
Présentation DEVOPS_.pptx
 
Présentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptxPrésentation DEVOPS_Black.pptx
Présentation DEVOPS_Black.pptx
 
Présentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptxPrésentation DEVOPS_Kola.pptx
Présentation DEVOPS_Kola.pptx
 
TDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoringTDD (Test Driven Developement) et refactoring
TDD (Test Driven Developement) et refactoring
 
At2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicAt2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville Public
 
devops.pdf
devops.pdfdevops.pdf
devops.pdf
 
Rex Software Factories 20140117 - Ensim
Rex Software Factories 20140117 - EnsimRex Software Factories 20140117 - Ensim
Rex Software Factories 20140117 - Ensim
 
20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven20090615 - Ch'ti JUG - Apache Maven
20090615 - Ch'ti JUG - Apache Maven
 
conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...conception et réalisation plateforme collaboratif basant sur la methode agile...
conception et réalisation plateforme collaboratif basant sur la methode agile...
 
L'integration continue pour tous
L'integration continue pour tousL'integration continue pour tous
L'integration continue pour tous
 
Usine logicielle à Orange Labs
Usine logicielle à Orange LabsUsine logicielle à Orange Labs
Usine logicielle à Orange Labs
 
NightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous DeliveryNightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous Delivery
 

Plus de Agile Tour 2009 Québec

Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Agile Tour 2009 Québec
 
Introduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM BromontIntroduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM Bromont
Agile Tour 2009 Québec
 
L’agilité dans des projets d’envergure
L’agilité dans des projets d’envergureL’agilité dans des projets d’envergure
L’agilité dans des projets d’envergure
Agile Tour 2009 Québec
 
Waste and Trashing
Waste and TrashingWaste and Trashing
Waste and Trashing
Agile Tour 2009 Québec
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
Agile Tour 2009 Québec
 
La technique Pomodoro
La technique PomodoroLa technique Pomodoro
La technique Pomodoro
Agile Tour 2009 Québec
 
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
Agile Tour 2009 Québec
 
Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire
Agile Tour 2009 Québec
 
Open Space
Open SpaceOpen Space
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
Agile Tour 2009 Québec
 
Exemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUMExemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUM
Agile Tour 2009 Québec
 

Plus de Agile Tour 2009 Québec (11)

Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
Aucun procesus ou méthode ne peut réparer votre organisation ... vous pouvez ...
 
Introduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM BromontIntroduction au Kanban et expérience pratique chez IBM Bromont
Introduction au Kanban et expérience pratique chez IBM Bromont
 
L’agilité dans des projets d’envergure
L’agilité dans des projets d’envergureL’agilité dans des projets d’envergure
L’agilité dans des projets d’envergure
 
Waste and Trashing
Waste and TrashingWaste and Trashing
Waste and Trashing
 
Pratiques de développement pour équipes Agile
Pratiques de développement pour équipes AgilePratiques de développement pour équipes Agile
Pratiques de développement pour équipes Agile
 
La technique Pomodoro
La technique PomodoroLa technique Pomodoro
La technique Pomodoro
 
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
L'agilité dans le monde de l'assurance: l'expérience vécue d'un virage comple...
 
Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire Intégration d'Agile dans un domaine multidisciplinaire
Intégration d'Agile dans un domaine multidisciplinaire
 
Open Space
Open SpaceOpen Space
Open Space
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
 
Exemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUMExemples et solutions : Difficultés de l’implémentation de SCRUM
Exemples et solutions : Difficultés de l’implémentation de SCRUM
 

Dernier

Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Laurent Speyser
 
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
Horgix
 
Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
UNITECBordeaux
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
Université de Franche-Comté
 
Les écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptxLes écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptx
abderrahimbourimi
 
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
OCTO Technology
 

Dernier (6)

Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
 
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
 
Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
 
Les écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptxLes écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptx
 
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
 

Processus d’intégration continue et outils

  • 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