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.

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.