Continuous Deliver

From air
Jump to navigation Jump to search


Le Continous Delivery : Click and Deploy

En combien de temps votre entreprise peut-elle déployer une application dans laquelle une seule ligne de code a été modifiée?


Cette problématique répond à l’utilité du concept du Continous Delivery (C.D). Le C.D est un ensemble de technique permettant que pour chaque modification du code, d’effectuer un ensemble de tests automatisé, pour que le code que soit prêt à être déployé directement à l'équipe de production. Si pour chaque commit le code :

  • Compilé, testé, déployé sur un environnement d’intégration = Continuous Integration
  • Compilé, testé, livré à l’équipe suivante (Tests, Qualification, Mise En Production, Ops) = Continuous Delivery

Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie Logiciel, l’intégration continue consiste à vérifier automatiquement et à chaque modification de code source que le résultat des modifications ne produit pas de régression. C'est à dire que si votre commit produit des erreurs sur les résultats, celui-ci ne sera pas accepté. (T'as le droit de tout péter, mais t'es obligé d'être au courant). L’intégration Continue permet de détectés rapidement les problèmes d’intégration et de les corrigés au fur et à mesure. Aussi grâce au test automatisés mis en place permette de d'identifier les changements problématique. Enfin de connaître et obtenir rapidement la dernière version stable de l'application


Fonctionnement Deploiement.png


Ainsi le C.D est une évolution de l’intégration Continue. Comme nous l'avons vu en Génie Logiciel, l’intégration continue consiste à vérifier automatiquement et à chaque modification de code source que le résultat des modifications ne produit pas de régression. C'est à dire que si votre commit produit des erreurs sur les résultats, celui-ci ne va pas être accepté. (T'as le droit de tout péter, mais t'es obligé d'être au courant). L’intégration Continue permet de détectés rapidement les problèmes d’intégration et de les corrigés au fur et à mesure. Aussi grâce au test automatisés mis en place permette de d'identifier les changements problématique. Enfin de connaître et obtenir rapidement la dernière version stable de l'application



Un petit rappel concernant l’intégration continue:

  • 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 (commit) quotidiennement (au moins) leurs modifications

Pour ce faire, il nécessite de contrôler plusieurs points:

  • Contrôler l'intégrité de l'application a chaque commit
  • S'assurer de l'absence de régressions
  • Mesurer la couverture du code
  • Surveiller le respect des conventions de codage
  • Signaler les erreurs de codage


Un exemple d'outils permettant l’intégration continue est Jenkins, souvent utilisé dans les projets Java développés avec maven, Jenkins est un serveur d’intégration qui s'interface avec des systèmes de gestion de versions tels que CVS, Git et Subversion, et exécute des projets basés sur Apache Ant, Maven... Jenkins fonctionne avec l'utilisation de Job, on peut configurer des jobs pour que celui-ci par exemple exécute un script à chaque commit ou bien permet de vérifier le bon fonctionnement du code. Une fois le job configuré, Jenkins permet d'obtenir des courbes de tests, d'analyse statique du code, un historique des productions effectuées. Et le tout de manière claire et simple:


Hudson-job-main-page.png

Un build représente sur Jenkis la creation d'un Job. Ainsi à chaque commit, le script

Maintenant revenant au Continous Delivery, celui-ci est simplement:


Automate.pngLe Continuous Delivery = C.I + des automates de test entièrement automatisé

En effet, le but est d'automatiser l'ensemble des dépendances, des build, des test...

  • Les tests de type "White-box". Ces tests vérifie la structure interne de l'application(code). Il s'agit de tester les implémentations.( donc on vérifie la compétence du programmeur)
  • logiciel: Fitnesse, Greenpepper, etc.
  • Les tests de type "Black-box". Ces tests vérifie eu la structure externe de l'application, on testera donc uniquement les entrées-sorties de l'application, et sa stabilité.
  • Logiciel: Gatling, OpenSTA, etc.

L’automatisation des tests peut semble assez coûteuse car assez complexe à mettre en place. Mais lorsque ceux-ci sont exécuter plusieurs par jour,(Certain test peuvent être lancé 1 millions de fois par jour)l'investissement est vite amortie

But du Continuous Delivery

Le Continous Delivery en plus de tous les avantages de l’intégration Continue permet d'améliorer la chaine de production.. En plus de tous les avantages de l’intégration Continue une des premières utilité du C.D est de réduire ce qu'on appel le" time to market.". De nos jours, de nombreuse applications ont besoin de se mettre rapidement à jour pour suivre les besoins des utilisateus. Par exemple un site de commerce à besoin de rapidement suivre les nouveautés ou de rajouter de nouvelles fonctionnalités. Le C.D permet de faire de faire ces déploiements rapides et sans sans risque. Le site Etsy (site de commerce en ligne), a investi énormément dans ses tests automatisés et ses outils de déploiement et effectue plus de 25 déploiements par jour. Facebook, très agressif sur l’automatisation des tests, effectue 2 déploiements par jour.

Ensuite comme le C.D permet des cycles rapides, grâce à des déploiements rapides et peu risqués on peut envisager des mises à jour fréquentes des applications installées.

ContinuousDelivery-Fig-2.png Aussi, on peut voir dans cette courbe que plus les déploiements sont fréquent (donc les modifications sont moins important), plus le Time To Repair est important. Ainsi avec le C.D le TTR est réduit et donc un grand gain de temps pour l'entreprise.

Exemple de Continuous Delevery

Voir aussi

Liens externes

Source Image

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