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 ...")
 
 
(79 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== 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.
 
   
  +
== Le Continous Delivery : Click and Deploy ==
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.
 
  +
'''En combien de temps votre entreprise peut-elle déployer une application dans laquelle une seule ligne de code a été modifiée?'''
   
  +
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.
 
  +
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
  +
  +
  +
  +
  +
[[File: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 commit quotidiennement (au moins une fois par jour) 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:
  +
  +
  +
[[File:Hudson-job-main-page.png]]
  +
  +
Un build représente sur Jenkis la creation d'un Job. Maintenant revenant au Continous Delivery, celui-ci est simplement:
  +
  +
  +
[[File:Automate.png]]'''Le 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 sembler assez coûteuse car assez complexe à mettre en place. Mais lorsque ceux-ci sont exécutés plusieurs fois par jour (Certain test peuvent être lancé 1 millions de fois par jour), l'investissement est vite amortie
  +
  +
== But du Continuous Delivery ==
  +
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.
  +
  +
[[File:ContinuousDelivery-Fig-2.png]]
  +
  +
Aussi, on peut voir dans cette courbe issue du site http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change-4608108, 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 Avec circleci et HEROKU ==
  +
  +
  +
Nous allons dans créer une application dans laquelle nous allons faire un peu d’intégration continue. Pour se faire nous alors utilisé Heroku qui permet de stocker notre application sur le cloud (Heroku est un service de cloud computing de type plate-forme en tant que service). CircleCi permet quand à lui d’effectuer des jobs de test, ou de cherchée les dépendances des fichiers.
  +
  +
Pour ce faire, prenons les fichiers contenue dans le Tutorial d’exemple d'Heroku https://devcenter.heroku.com/articles/getting-started-with-python#introduction. Notre applis consiste simplement à afficher des mots à l'écran.:
  +
from flask import Flask
  +
app = Flask(__name__)
  +
@app.route("/")
  +
def hello():
  +
return "Hello World, I love continuous delivery a lot!"
  +
if __name__ == "__main__":
  +
app.run()
  +
  +
Lorsqu'on nous avons finis de configurer notre application Heroku, nous allons maintenant crée un test unitaire simple qui consiste à vérifier si hello est compris dans la phrase.
  +
  +
import unittest
  +
from .hello_app import app
  +
class HelloTest(unittest.TestCase):
  +
def setUp(self):
  +
self.app = app.test_client()
  +
def test_root(self):
  +
assert 'Hello' in self.app.get('/').data
  +
  +
Maintenant, modifiant la phrase mais gardant le mot hello dans la phrase :
  +
[[File:Demo_1.PNG]]
  +
  +
Lors du commit, un build est lancé automatiquement sur Circleci:
  +
  +
[[File:Demo_2.PNG]]
  +
  +
  +
  +
Quelques minutes plus tard:
  +
  +
  +
  +
[[File:Demo 3.PNG]]
  +
  +
On peut voir que le build à été un succès, et ainsi notre application stockée sur Heroku à été mise à jour. Pour vérifier on lance la commande:
  +
heroku open
  +
[[File:Data 6.PNG]]
  +
  +
Maintenant modifiant la phrase de tel maniéré à ce que "Hello" n’apparaisse plus et donc que le test ne fonctionne plus:
  +
[[File:Data 9.PNG]]
  +
  +
  +
  +
Resultat: lorsque l'on commit le code, le build à échoué à cause de l’exécution du test:
  +
[[File:Data_10.PNG]]
  +
  +
Et lorsqu'on lance l'application heroku:
  +
  +
On remarque qu'il n'y a eu aucun changement, tant que le build n'est pas correct, aucune modification de l'application n'est effectué.
  +
[[File:Data 12.PNG]]
  +
  +
== 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.
  +
  +
== Source Image==
  +
  +
* http://blog.octo.com/devops-de-lintegration-continue-au-deploiement-continu/
  +
* http://igm.univ-mlv.fr/~dr/XPOSE2010/Lecharpentier_Jenkins/images/hudson-job-main-page.png

Latest revision as of 18:28, 5 February 2015


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



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 commit quotidiennement (au moins une fois par jour) 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. 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 sembler assez coûteuse car assez complexe à mettre en place. Mais lorsque ceux-ci sont exécutés plusieurs fois par jour (Certain test peuvent être lancé 1 millions de fois par jour), l'investissement est vite amortie

But du Continuous Delivery

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 issue du site http://www.slideshare.net/jallspaw/ops-metametrics-the-currency-you-pay-for-change-4608108, 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 Avec circleci et HEROKU

Nous allons dans créer une application dans laquelle nous allons faire un peu d’intégration continue. Pour se faire nous alors utilisé Heroku qui permet de stocker notre application sur le cloud (Heroku est un service de cloud computing de type plate-forme en tant que service). CircleCi permet quand à lui d’effectuer des jobs de test, ou de cherchée les dépendances des fichiers.

Pour ce faire, prenons les fichiers contenue dans le Tutorial d’exemple d'Heroku https://devcenter.heroku.com/articles/getting-started-with-python#introduction. Notre applis consiste simplement à afficher des mots à l'écran.:

from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
   return "Hello World, I love continuous delivery a lot!"
if __name__ == "__main__":
    app.run()

Lorsqu'on nous avons finis de configurer notre application Heroku, nous allons maintenant crée un test unitaire simple qui consiste à vérifier si hello est compris dans la phrase.

import unittest
from .hello_app import app
class HelloTest(unittest.TestCase):
def setUp(self):
   self.app = app.test_client()
def test_root(self): 
   assert 'Hello' in self.app.get('/').data

Maintenant, modifiant la phrase mais gardant le mot hello dans la phrase : Demo 1.PNG

Lors du commit, un build est lancé automatiquement sur Circleci:

Demo 2.PNG


Quelques minutes plus tard:


Demo 3.PNG

On peut voir que le build à été un succès, et ainsi notre application stockée sur Heroku à été mise à jour. Pour vérifier on lance la commande:

heroku open

Data 6.PNG

Maintenant modifiant la phrase de tel maniéré à ce que "Hello" n’apparaisse plus et donc que le test ne fonctionne plus: Data 9.PNG


Resultat: lorsque l'on commit le code, le build à échoué à cause de l’exécution du test: Data 10.PNG

Et lorsqu'on lance l'application heroku:

On remarque qu'il n'y a eu aucun changement, tant que le build n'est pas correct, aucune modification de l'application n'est effectué. Data 12.PNG

Voir aussi

Liens externes

Source Image