Choisir son outil pour automatiser les déploiements

Depuis le traditionnel outil make, introduit en 1977 pour livrer en production un logiciel, plusieurs étapes, de la construction du logiciel au processus de livraison, ont été automatisées. En réalité, être professionnel lorsqu’on parle de développer des logiciels, c’est, a minima, savoir automatiser la compilation et les tests en intégration continue. Mais un autre sujet progresse aussi dans le domaine de la gestion du cycle de vie des applications (Application Lifecycle Management – ALM), il s’agit de l’automatisation des déploiements. Cette progression est en partie due à nos environnements (serveurs d’application, ESB, EAI, etc.) qui sont de plus en plus complexes et étendus. Le nombre croissant de nouvelles versions d’une application, demandées par le business moderne, et le fait que le déploiement doit être suffisamment fiable pour ne pas risquer d’interrompre un service en ligne sont deux raisons supplémentaires qui poussent à s’intéresser à cette question. Ajoutez à cela que les infrastructures en cloud gagnent un peu plus de terrain chaque jour, et vous conviendrez que l’on a encore un long chemin, à la fois motivant et intéressant, à parcourir.

Est-ce que nos outils de packaging actuels peuvent déployer nos applications?

Dans cet article, je souhaite comparer l’automatisation du déploiement au plus connu des processus automatiques du développement logiciel : le packaging de l’application. En simplifiant, le processus de packaging part du code source pour le transformer en code exécutable. La façon la plus simple pour créer ce code est d’utiliser un script shell qui lance le compilateur, mais ce processus a beaucoup mûri. Grâce à des outils comme Make, cité précédemment, mais aussi à Ant et Maven, l’utilisateur peut spécifier de manière très détaillée tout le processus. Prenons l’exemple de Maven, la plupart des projets n’ont plus besoin de scripter quoique soit. Le fichier POM décrit les composants du projet, les plugins utilisés, et la façon de packager l’application. Et en ce moment même, de nouveaux outils font leur apparition, comme Gradle, qui offre encore un peu plus de flexibilité.

Mais ces outils nous permettent-ils de faire du déploiement automatique? Dans un billet précédent, mon collègue Robert van Loghem a expliqué en quoi le déploiement est un processus complexe qui inclut un certain nombre d’étapes comme l’installation des EAR/WAR, la configuration des datasources et le redémarrage des serveurs.
Bien que Wikipedia inclut la fonction de déploiement vers des systèmes en production, lorsqu’il définit l’automatisation du packaging, les outils actuels n’ont pas intégré ces concepts de packages de déploiement (i.e. les livrables), les environnements cibles (test, recette, production, etc.) ou la modification des valeurs selon l’environnement. En réalité, ils n’ont pas de connaissances liées aux middlewares sur lesquels on déploie et ne proposeront certainement jamais des scenarii de déploiement. Au final, ce qu’offrent ces outils, c’est le moyen de scripter, bien connu des développeurs, et de stocker ces scripts avec les sources à installer. Cela amène irrémédiablement à de nombreux scripts « maison » pour automatiser les déploiements.

Mais ce n’est pas tellement surprenant. Dans Wikipedia, les pré-requis d’un système d’automatisation ne mentionnent pas le Déploiement. Un système de déploiement automatique a pour objectif de déployer du code exécutable sur un environnement cible, alors que le système d’automatisation du packaging ne fait que produire ce code exécutable.

build_automation_to_deployment_automation

Les pré-requis nécessaires pour que notre outil déploie

Voici une liste de pré-requis que devrait satisfaire un outil de déploiement automatique :

  • Avoir nativement les concepts de base du déploiement : packages, environnements, lien entre les middlewares, etc.
  • Support inclus pour les middlewares principaux avec une possibilité de l’étendre.
  • Support inclus pour les scenarii courants de déploiement avec un moyen de les personnaliser.
  • Proposer une séparation des rôles : les développeurs livrent le projet, un groupe d’administrateur définit les environnements et un autre groupe déploie l’application, etc.
  • Supporter une charge croissante d’environnements avec plusieurs applications et de nombreux utilisateurs.
  • Être capable de faire des déploiements multi-plateformes : des environnements complexes peuvent s’étendre sur de multiples systèmes d’opération et versions.

Les outils d’automatisation de packaging ne répondent pas à ces pré-requis et vouloir les étendre ne fera que complexifier leur utilisation sans pour autant faciliter convenablement les déploiements.
Cela explique l’émergence d’outils de déploiement automatique, qui ont dépassé les anciens outils de scripts « maison ».

Que l’on soit bien d’accord, les outils de déploiement automatique ne remplacent pas les outils d’automatisation des packages. Mais les deux ont leur place dans le paysage des livraisons d’applications. Les outils de packaging produisent le code exécutable et les outils de déploiements s’assurent de rendre ce code disponible pour les utilisateurs finaux !

Dans le prochain article de cette série, nous expliquerons en quoi le déploiement automatique est différent du mécanisme de gestion des livraisons de nouvelles versions.


Traduction libre du billet « Deployment automation vs. build automation » publié par Vincent Partington sur blog.xebia.com.

Publié par

Publié par Emmanuel Servent

Emmanuel a rejoint Xebia en 2008 après quatre années passées à Unilog. Il associe les compétences techniques de l'écosystème Java à une prise de responsabilités sur l'encadrement d'équipes. Il tire son expérience des nombreux projets délicats rencontrés autant par le niveau d'exigence de l'application que par les délais à respecter.

Commentaire

7 réponses pour " Choisir son outil pour automatiser les déploiements "

  1. Publié par , Il y a 9 ans

    Entièrement d’accord, les outils de build ne devraient pas avoir la responsabilité du déploiement.

    J’ai l’impression que cette confusion est née à cause de la phase « deploy » de Maven. En fait la phase deploy rend accessible l’artefact construit, rien à voir avec un deploy sur un serveur.

    Pour un module de niveau « framework », le déploiement consiste juste à rendre accessible le jar.
    Et pour un artefact WAR ou EAR ? Et bien j’aurais tendance à faire comme ceci : l’outil de build dépose l’artefact dans le repository Maven. L’outil de déploiement s’appuyant sur le repository, récupère cet artefact, le repackage au besoin en fonction de l’environnement, et l’installe dans un serveur.

    Il vaut mieux faire comme ça car une application peut nous être livrée de l’extérieur, pré-packagée. Cela serait donc bizarre de devoir utiliser un outil comme Hudson ou Cruise control pour réaliser le déploiement …

    De plus, pourquoi faudrait il rebuilder l’artefact pour refaire un déploiement à l’identique ? Supposons que le serveur de recette soit arrêté, doit on refaire tout le build et perdre ainsi un temps fou ? On voit bien qu’il est nécessaire de séparer conceptuellement les deux. Avec pour ma part le repo Maven comme zone franche ^^

  2. Publié par , Il y a 9 ans

    Je ne trouve pas forcément choquant d’utiliser Hudson comme outil de déploiement… au moins pour les environnements accessibles aux dev.

    Nous avons un environnement de « dev ». A chaque commit, Hudson lance le build, et si le build s’est bien passé, déploie l’application en dev. Ainsi, les dernières fonctionnalités sont toujours présentes en dev.

    Par ailleurs, nous avons aussi un environnement de « recette », sur lequel on souhaite déployer de nouvelles versions « manuellement » (à la demande), et pas automatiquement. « Manuellement » ne veut pas dire « compliqué ». Le déploiement en recette est réalisé via le plugin Cargo de Maven. Cependant : la release est réalisée via Hudson (Hudson release plugin), et un job Hudson à part permet de déployer une version du repo en recette, à la demande.

    Ainsi, n’importe qui peut déclencher une release, et réaliser une mise en recette, en quelques clics.

    Cargo n’est probablement pas aussi bien outillé que DeployIT (on sent bien que c’est un peu le but sous jacent de l’article), mais il convient à nos besoins.

  3. Publié par , Il y a 8 ans

    c’est bien comme article, surtout que c’est la traduction a la lettre de l’article http://java.dzone.com/articles/deployment-automation-vs-build, Submitted by Vincent Partington on Wed, 2010/10/13 – 1:56am , paru quelques 2 moins avant cette publication, quand on recopie ou on va chercher sur internet un travail fait par un autre. Lorsque vous citez votre source, vous faites la preuve de votre capacité à rechercher des informations. Lorsque vous ne la citez pas, vous volez le travail d’un autre en le faisant passer pour le vôtre. C’est un plagiat

  4. Publié par , Il y a 8 ans

    Bonjour Digas,

    Je ne comprends pas bien ce que vous dites. Vincent a publié son article la veille sur le blog de Xebia Hollande et cette référence est inscrite à la toute fin de l’article.

    « Traduction libre du billet « Deployment automation vs. build automation » publié par Vincent Partington sur blog.xebia.com. »

    En tout cas, je vous remercie pour votre commentaire « traduction à la lettre », j’apprécie beaucoup, c’est justement ce que je recherchais…

    Cordialement,
    Emmanuel Servent.

  5. Publié par , Il y a 8 ans

    Bonjour,

    je me posais la question de l’interet de DeployIt en environnement Websphere etant donné que le Manager Websphere via son interface graphique propose ce déploiement automatique ?

  6. Publié par , Il y a 8 ans

    Bonjour,
    Effectivement Websphere propose une interface graphique pour effectuer la configuration des resources (Datasource, VirtualHost, JMS…) et le déploiement des applications (War, Ear,…). Effectuer toutes ces opérations sont longues et répétitives donc à la fin source d’erreur. Le concept de Deployit est de pouvoir packager et de déployer l’application en incluant non seulement les binaires (Ear,War) , les resources associées (DataSource,…) mais également le SQL, les fichiers de configuration avec remplacement de valeur en fonction de l’environment, la configuration apache, les resources Web (Images, JS, video, HTML).

    1/3 des utilisateurs de Deployit l’utilise avec pour middleware principal WebSphere, en particulier KLM http://www.xebialabs.com/KLM-relies-on-deployit-for-deployment-automation (témoignage video http://www.youtube.com/watch?v=TLvvLaSc1wY)

    donc Oui, il y a un interêt à Deployit dans une environment WebSphere.

    Cordialement
    Benoit Moussaud.

  7. Publié par , Il y a 8 ans

    Bonjour,
    En complément du post de Benoit Moussaud, Directeur Technique chez XebiaLabs, sachez que la BGPI (Banque de Gestion Privée Indosuez) du groupe Crédit Agricole et basée à Paris, utilise Deployit depuis plus d’un an maintenant pour déployer des applications WebSphere si vous souhaitez avoir des retours d’expérience. N’hésitez pas à nous contacter pour plus d’informations, nous pourrons vous mettre en relation.

    A votre disposition.

    Cordialement, Richard

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.