Difference between revisions of "Continuous Deliver"

From air
Jump to navigation Jump to search
(Created page with "== Introduction == L'Intégration Continue ne devrait pas s'arrêter une fois que votre application compile correctement. Elle ne devrait pas non plus s'interrompre une fois ...")
 
Line 1: Line 1:
  +
Avant de parler de continous deliver, il est important dans un premier temps de rappeler l’intégration continue :
−
== Introduction ==
 
−
L'Intégration Continue ne devrait pas s'arrêter une fois que votre application compile correctement. Elle ne devrait pas non plus s'interrompre une fois que des tests, contrôles automatiques ou audit de la qualité du code puissent être lancés. L'enchainement naturel, une fois toutes ces étapes mises en oeuvre, est d'étendre votre processus de construction automatisé au déploiement. Cette pratique est connue globalement sous le nom de Déploiement Automatisé ou Déploiement Continu.
  
   
−
Dans sa forme la plus élaborée, le Déploiement Continu est le processus où toute modification du code, dotée des tests automatisés et autres vérifications appropriées, est immédiatemement déployée en production. Le but est de réduire la durée du cycle ainsi que le temps et l'effort du processus de déploiement. Cela aide également les équipes de dévelopemment à réduire le temps nécessaire pour livrer des fonctionnalités individuelles ou des corrections de bogue, et par conséquent augmente significativement la productivité des équipes. Réduire ou éliminer ces périodes d'intenses activités menant à une livraison traditionnelle ou à un déploiement libère également du temps et des ressources pour améliorer les processus et pour l'innovation. Cette approche est comparable à la philosophie de l'amélioration continue promue par des processus Lean tel que Kanban.
  
   
  +
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 [[Non-régression|pas de régression]] dans l'application développée.
−
Cependant, déployer systématiquement le dernier code en production n'est pas toujours approprié, quelque soit la qualité de vos tests automatisés. De nombreuses organisations ne sont pas préparées à ce que de nouvelles versions apparaissent sans annonce chaque semaine. Des utilisateurs ont peut être besoin d'être formés, du marketing peut être nécessaire autour du produit et ainsi de suite. Une variante plus conservative de ce principe, souvent vue dans les organisations de grande taille, est d'avoir le processus de déploiement entièrement automatisé mais de déclencher le déploiement effectif via un mécanisme à un clic. Cela est connu sous le nom de Livraison Continue, et a tous les avantages du Déploiement Continu sans ses inconvénients. Des variantes au processus de Livraison Continue peuvent aussi impliquer des déploiements automatisés vers certains environnement (tels que test et AQ) tout en utilisant un déploiement manuel à un clic pour d'autres environnements (tels que recette et production). La caractéristique la plus importante de la Livraison Continue est que chaque build ayant passé avec succès tous les tests automatisés et vérifications de qualités appropriés puisse être potentiellement déployé en production au moyen d'un processus entièrement automatisé et déclenché via un clic, au choix de l'utilisateur final et en quelques minutes. Le processus n'est cependant pas automatique : c'est l'équipe métier et non informatique qui décide du meilleur moment pour livrer les dernières modifications.
  
  +
Bien que {{Référence nécessaire|le concept existât auparavant}}
  +
, 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<span id="mwDQ"> </span>:
−
Le Déploiement Continu et la Livraison Continue sont tous deux considérés, à juste titre, comme signes d'un haut niveau de maturité en termes de processus de build et de pratiques SDLC. Ces techniques ne peuvent exister sans un ensemble très solide de tests automatisés. Pas plus qu'ils ne peuvent exister sans un environnement d'Intégration Continue et un séquenceur de build robuste. En effet, le Déploiement Continu ou la Livraison Continue représente généralement la dernière étape et le but d'un pipeline de build. Cependant, vu les avantages significatifs que ces pratiques apportent, elles sont un objectif pertinent. Dans la suite de ce chapitre nous allons utiliser le terme "Déploiement Continu" pour parler tant de Déploiement Continu que de Livraison Continue. En effet, le Déploiement Continu peut être vu comme la Livraison Continue avec une étape finale (le déploiement en production) dictée par la partie métier plutôt que l'équipe de dévelopement.
  
  +
* le [[code source]] soit partagé (en utilisant des [[Logiciel de gestion de versions|logiciels de gestion de versions]] tels que [[Concurrent versions system|CVS]], [[Subversion (logiciel)|Subversion]], [[git]], [[Mercurial]], etc)
  +
* les développeurs intègrent (''{{lang|en|commit}}'') quotidiennement (au moins) leurs modifications
  +
* des [[Test d'intégration|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 (informatique)|Jenkins]] ([[Fork (développement logiciel)|fork]] de [[Hudson (Informatique)|Hudson]]) pour le langage [[Java (langage)|Java]] par exemple.
  +
  +
Les principaux avantages d'une telle technique de développement sont<span id="mwIQ"> </span>:
  +
  +
* 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 (informatique)|dépôt]] unique de [[code source]] versionné
  +
* Automatiser les compilations
  +
* Rendre les compilations auto-testantes
  +
* Tout le monde ''{{lang|en|commit}}'' tous les jours
  +
* Tout ''{{lang|en|commit}}'' doit compiler le tronc ({{lang|en|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 (informatique)|Jenkins]] ([[Fork (développement logiciel)|fork]] de [[Hudson (Informatique)|Hudson]]), serveur d'intégration continue pour [[Plate-forme Java|Java]]
  +
* [[Tinderbox (logiciel)|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 ===
  +
  +
* [http://www.martinfowler.com/articles/continuousIntegration.html Continuous Integration] par Martin Fowler
  +
* [http://gump.apache.org/ Apache Gump]
  +
* [http://cabie.tigris.org/ CABIE]
  +
* [http://www.jetbrains.com/teamcity/index.html TeamCity]
  +
* [https://travis-ci.org/ Travis CI] propose un service d'intégration continue gratuit aux projets open sources.

Revision as of 21:29, 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 :

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 Template:Lang tous les jours
  • Tout Template:Lang doit compiler le tronc (Template:Lang) 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

Liens externes

Retrieved from "https://air.imag.fr/index.php?title=Continuous_Deliver&oldid=19659"