Deployit sous toutes ses coutures
Aujourd’hui nous allons présenter l’outil de déploiement édité par notre partenaire technique XebiaLabs : Deployit. Il faut avouer que j’ai été plutôt impressionné par ce qu’ils ont créé.
Globalement, XebiaLabs avec Deployit, vous propose de rationaliser le déploiement de vos applications. Ce produit est la passerelle technique entre les applications et les serveurs sur lesquels elles s’installent. De plus, en prenant en charge ces déploiements, l’outil va vous permettre de les automatiser. N’oublions jamais que plus l’intervention humaine est importante, plus le risque d’erreur augmente.
XebiaLabs, avec Deployit, propose de rationaliser vos déploiements. Ce produit est la passerelle technique entre les applications et les serveurs sur lesquels elles s’installent.
DeployIt, une application entre deux mondes[/caption]
Petite présentation de Deployit
Deployit permet de simplifier vos procédures de déploiement.
Ce que j’ai apprécié est qu’une fois que vous avez lié votre application à un environnement, et configuré le déploiement, celui-ci peut se faire automatiquement. Ce qui signifie qu’après la période initiale de mise en place, Deployit ne nécessite pas forcement beaucoup de maintenance et sait se « faire oublier ».
Second point intéressant, Deployit vous propose d’interagir avec lui par le biais d’une api REST. Les clients fournis pour Deployit (une webApp et une CLI – Command Line Interface) se basent sur cette même api. Du coup, ce que vous pouvez faire au travers du GUI, vous pouvez l’automatiser au travers de l’API.
Deployit est un produit écrit en Java. Cependant il s’adresse vraiment à tout le monde, y compris aux clients .NET avec ses plugins IIS et Biztalk (je ne les ai pas testés pour le moment, le test plus complet arrive).
Comment cela se passe ?
Deployit a besoin de différentes données pour fonctionner :
- Des environnements (Où déployer)
- Des applications (Quoi déployer)
- Des plugins (Comment déployer)
Et ces trois points se retrouvent dans leur interface graphique :
Panneau principal de Deployit[/caption]
A gauche vous retrouverez vos applications, à droite vos environnements, et au milieu vos plugins au travers des liaisons qui vous sont permises. En effet, j’ai un plugin JBoss qui sait déployer un EAR dans un JBoss, la relation verte entre les deux éléments apparaît donc.
Et voilà, votre application est prête à être déployée. Un petit appui sur le bouton « next » et le tour est joué : votre application est déployée.
Fenêtre de résumé de déploiement[/caption]
Avec la fenêtre de résumé, on peut voir ce qui s’est passé, et surtout lire les logs si besoin. En cas d’erreur, il vous faudra appuyer sur le bouton rollback qui vous remettra dans l’état exact où se trouvait l’application initialement (configuration incluse).
Voilà, vous avez les bases 🙂
Mais creusons un peu. Voyons ce que Deployit prend en entrée.
Unified Deployment Model
Deployit se base sur cet UDM pour savoir quoi faire. On retrouvera donc bien évidement l’aspect ‘deployable’ et l’aspect environnement.
Deployit vous permet de déployer une archive de déploiement sur un environnement en utilisant un mapping décrit dans des plugins.
L’archive de déploiement : le DAR, « Deployment Archive »
Le DAR représente ce que vous voulez déployer : Quoi déployer ?
Cette archive se veut cross environnement. C’est l’application qui contient les configurations valables pour tous les environnements. Mais vous y trouverez des scripts de base de données, des images, des fichiers compilés, des fichiers statiques, mais également les différentes ressources nécessaires (DataSources, Virtual Hosts, etc.). En bref, des applications avec leur écosystème.
Le package (DAR) est généralement produit par les équipes de développement.
Les Environnements : les « Containers »
Les environnements correspondent aux serveurs et middlewares sur lesquels vous allez déployer : Où déployer ?
Votre environnement est un ensemble de containers qui correspondent à un serveur JBoss, un serveur IIS, un host linux, des instances hadoop, des machines sur le cloud, …
En bref, ces containers vont pouvoir héberger et faire tourner vos applications. De plus c’est ici que vont être stockées les configurations propres à l’environnement.
Notez que cette partie est généralement le domaine de l’OPS, de la production.
Les Plugins
Cette partie correspond à la question : Comment déployer ?
Le plugin a pour objectif de fournir le processus permettant de déployer telle typologie d’applicatif sur telle typologie de container. Typiquement un plugin SQL permettra d’exécuter des scripts en *.sql sur une instance SQL, SQLite, ou autre base de donnée SQL. Un plugin de déploiement JBoss permettra de déployer un EAR ou autre application sur un container de type JBoss.
Et l’extensibilité dans tout ça ?
J’ai adoré. Dans toutes les sociétés il y a des impératifs à suivre dans l’installation de telle ou telle brique applicative et généralement il y a un manuel d’installation un peu custom (pour ne pas dire un manuscrit obscur écrit et compris par une unique personne). Le mieux est de faire un script d’installation mais voilà, il marchera dans certains cas et pas dans d’autre… C’est toujours dans ce genre de moments qu’il y a un changement d’architecture et qu’il faut refaire le script en urgence.
En vous permettant de développer vos propres plugins ou des spécialisations de plugins existants, Deployit va vous permettre de définir la typologie de votre application custom, de définir le type de container dont elle a besoin pour fonctionner une fois pour toute. Une fois votre plugin fait, que vous avez défini comment déployer votre application sur tel container, vous pouvez l’inclure dans Deployit et à vous les déploiements à la chaîne.
Quant aux connaissances nécessaires pour mettre en place des plugins, je dirais de lire le manuel et de connaître le xml si on veut spécialiser un plugin existant ou en créer un nouveau (generic-plugin). L’utilisation de l’API Java reste exceptionnelle mais permet d’aller au plus près du moteur et donc de créer des plugins à logique plus complexe.
Ce que j’ai aimé
Maintenant que je vous ai présenté en gros Deployit (vraiment en gros car cet outil est vraiment complet), je vais passer rapidement sur les points qui m’ont plu.
Les dictionnaires de config
Nous avons vu plus haut que les packages de déploiement ne doivent pas dépendre de l’environnement sur lesquels ils vont être déployés. De coup les configurations sont mises côté environnements.
J’ai particulièrement apprécié ce système de gestion de configuration. Vous allez mettre dans les settings de vos applications des « Place Holders » du type « {{DatabaseServerUri}} », et si vous avez dans le dictionnaire de votre environnement une valeur pour la clé « DatabaseServerUri », elle sera remplacée.
De plus avec la version 3.8, il est possible d’avoir des dictionnaires de config cryptés ! Et ça c’est pratique !
Le release Dashboard
Il y a généralement deux choses que je n’aime pas dans les développements en entreprise : les « ninja commit » quand c’est le développeur qui prépare les packages (ne me lancez pas je pourrais en parler des heures), et l’absence de suivi quand on demande à mettre un correctif en production quand ce sont les ops qui s’en occupent.
Deployit a une vue qui permet de suivre l’évolution d’un package sur les différents environnements. Cela permet de sécuriser le flux de déploiement puisque l’application passera par tous les environnements de tests avec les mêmes sources (et oui, le package applicatif ne dépend pas de l’environnement) et d’avoir un suivi sur ce qu’il manque pour passer de tel à tel environnement. Puisqu’une image vaut plus qu’un long discours, voici l’écran que j’ai adoré :
Release Dashboard[/caption]
J’ai déployé une V1 en CI qui bug, du coup aucune version n’a été livrée en PP, et je viens de livrer la version 2.0 sur le JBoss de DEV. Résultat, deployit me propose de la livrer en CI.
L’API
Deployit fournit une api complète. La preuve en est que ses clients (aussi bien web que le CLI) ne font que les appeler. Vous aurez donc à configurer une fois vos déploiements depuis l’outil (je pense que c’est plus simple) et après, à vous l’automatisation à partir des API.
Vous pourrez piloter Deployit depuis un build Cruise Control, TFS, Maven ou Jenkins.
Mais aussi
En plus de ces points importants, une autre chose qui m’a plu est le système de droits assez intelligents. En effet, il y a par exemple la permission d’initier un déploiement qui est différente du droit de la déployer. Certaines personnes doivent avoir le droit de créer des environnements et pas d’autres. C’est bien d’y avoir pensé !
Il y a aussi des rapports qui permettent de connaître le taux de succès des déploiements etc…
Le panneau des rapports fournis par l’outil[/caption]
Et bien sûr vous retrouverez les fameux logs d’activité qui vous permettront de savoir rapidement quand le déploiement a été fait, par qui il a été demandé, etc… Bref, la notion de suivi d’activité est présente dans l’outil.
Conclusion
Après ce bref aperçu de Deployit, je dois dire que j’ai été impressionné de voir qu’on pouvait fournir un outil de déploiement assez flexible et valable pour tous. Non pas que ça n’existait pas avant, mais chaque société avait son outil custom qui marchait dans certains cas et pas dans d’autres.
Coté outil, Deployit est un écosystème. Il sert principalement d’orchestrateur à des plugins qui vont eux faire le boulot. XebiaLabs propose un bon nombre de plugins, majoritairement pour le monde java mais le .NET n’est pas en reste avec le nouveau plugin IIS que je compte tester rapidement.
J’ai beaucoup apprécié leur manière de faire. En effet, les plugins sont des sortes de contrats. Si on leur fournit tel type de déployable, et tel type d’endroit où déployer, ils savent faire le déploiement, revenir en arrière en cas de soucis, etc… C’est vraiment un plus car la plupart des scripts que j’ai pu voir étaient assez obscurs et connus uniquement de leur créateur. Avoir un contrat clair permet de s’y retrouver facilement et surtout de pouvoir réutiliser ou modifier assez facilement telle ou telle procédure.
Si vous avez des problématiques de déploiement dans votre société, réfléchissez maintenant à deux fois avant de réinventer la roue : Deployit est peut-être fait pour vous !
Pour aller plus loin, je vous recommande d’aller jeter un œil au manuel de l’interface de Deployit que vous trouverez ici : https://docs.xebialabs.com/releases/3.9/deployit/guimanual.html. Vous pourrez y trouver une liste un peu plus complète des nombreuses fonctionnalités proposées par l’outil.