Processus d’intégration continue et outils

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/

Processus d’intégration continue et outils

by Agile Tour 2009 Québec

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Processus d’intégration continue et outils Document Transcript