Difference between revisions of "Continuous Deliver"
Line 21: | Line 21: | ||
== Pratiques == |
== Pratiques == |
||
− | * Maintenir un |
+ | * Maintenir un Dépôt unique de code source versionné |
* Automatiser les compilations |
* Automatiser les compilations |
||
* Rendre les compilations auto-testantes |
* Rendre les compilations auto-testantes |
||
− | * Tout le monde |
+ | * Tout le monde commit tous les jours |
− | * Tout |
+ | * Tout commit doit compiler le tronc trunk sur une machine d'intégration |
* Maintenir un cycle de compilation court |
* Maintenir un cycle de compilation court |
||
* Tester dans un environnement de production cloné |
* Tester dans un environnement de production cloné |
Revision as of 21:30, 16 November 2014
Avant de parler de continous deliver, il est important dans un premier temps de rappeler l’intégration continue :
L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée.
Bien que Template:Référence nécessaire
, l'intégration continue se réfère généralement à la pratique de l'extreme programming.
Pour appliquer cette technique, il faut d'abord que :
- le code source soit partagé (en utilisant des logiciels de gestion de versions tels que CVS, Subversion, git, Mercurial, etc)
- les développeurs intègrent (Template:Lang) quotidiennement (au moins) leurs modifications
- des tests d'intégration soient développés pour valider l'application (avec JUnit par exemple)
Un outil d'intégration continue est ensuite nécessaire, tel que TeamCity, CruiseControl ou Jenkins (fork de Hudson) pour le langage Java par exemple.
Les principaux avantages d'une telle technique de développement sont :
- le test immédiat des modifications
- la notification rapide en cas de code incompatible ou manquant
- 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
- une version est toujours disponible pour un test, une démonstration ou une distribution
Pratiques
- Maintenir un Dépôt unique de code source versionné
- Automatiser les compilations
- Rendre les compilations auto-testantes
- Tout le monde commit tous les jours
- Tout commit doit compiler le tronc trunk sur une machine d'intégration
- Maintenir un cycle de compilation court
- 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
Voir aussi
- Jenkins (fork de Hudson), serveur d'intégration continue pour Java
- Tinderbox, serveur d'intégration continue de la Mozilla Foundation
- Apache Continuum, server de l'Apache Software Foundation
- Team Foundation Server, serveur Microsoft
- TeamCity
Liens externes
- Continuous Integration par Martin Fowler
- Apache Gump
- CABIE
- TeamCity
- Travis CI propose un service d'intégration continue gratuit aux projets open sources.