Acheter ou développer en interne : telle est la question de l’outillage DevOps
Avant même de choisir son outillage DevOps, une entreprise doit connaître ses forces et ses faiblesses. Un pipeline pré-configuré est certes plus simple qu’une série d’outils non intégrés, mais au détriment de la flexibilité.
Le monde de l’IT serait tellement plus facile si les entreprises pouvaient acheter DevOps.
Avec DevOps, il n’y a en effet aucune promesse de gratification immédiate. Il s'agit d'un état d'esprit et d'une approche liés aux processus de développement et des releases, et non d'une catégorie de produits spécifiques. Pourtant, il est une question que de nombreux adeptes DevOps se posent : comment développer - ou acheter - le bon pipeline DevOps ?
Si nombre d’entreprises, tous secteurs confondus, adhèrent aux principes et aux bonnes pratiques de DevOps, les chaînes d'outils et des processus de DevOps diffèrent d’une entreprise à l’autre, d’un déploiement à l’autre. Il existe plus d'une façon d'implémenter et d'automatiser le développement d'applications, le versioning et le support, et l’outillage suit également la même voie – chacun ayant ses préférences.
DevOps est une philosophie centrée sur l'outil, explique le cabinet d’analystes Gartner. Étant donné que DevOps est idéalement lié à d'autres processus de développement logiciel et IT, il est intrinsèquement opposé à la standardisation de l'ensemble des outils. Il existe un écosystème dynamique de produits DevOps - principalement open source - pour automatiser et simplifier les pipelines de delivery. Certains éditeurs vendent des chaînes DevOps de bout en bout.
Une chaîne d'outils DevOps préfabriquée a en effet de quoi séduire. Elle élimine les tâches d'intégration de l’outillage - les projets open source nécessitent généralement une forte personnalisation. Certaines DSI, en particulier celles qui ne connaissent pas DevOps, le développement Agile ou encore la livraison continue, préfèrent s'adapter à un flux de travail défini et apporté tel quel par un outil. Le fournisseur gère l'intégration de la chaîne d'outils, et cela a un prix. Même si le coût n'est pas un facteur dissuasif, cette approche doit être vérifiée par toute l’entreprise qui a déjà mis en place des processus et un cycle de vie des applications.
Des outils DevOps dans le cloud
Une entreprise qui développe des applications sur un Paas ou un Iaas préferera sans doute choisir un processus conçu pour cette plateforme ou ce fournisseur de cloud. Cloud Foundry, Microsoft Azure App Service et Amazon Web Services (AWS) en sont des acteurs de premier ordre.
AWS met par exemple à disposition plusieurs services qui ciblent différents segments du cycle de développement et de la chaîne DevOps. AWS CodeStar vise ainsi à simplifier la configuration du pipeline DevOps. Les utilisateurs développent et déploient des applications via un ensemble de templates qui exposent des services type d’AWS, tels que Elastic Compute Cloud (EC2), Elastic Beanstalk et Lambda. Cinq langages et plusieurs environnements de développement intégré (IDE) sont supportés.
CodeStar fournit un ensemble d’outils de gestion de projet logiciel avec une interface les services AWS. Avec les modèles CodeStar, un utilisateur automatise le provisioning de l'infrastructure (par exemple, sur EC2) et celui d'autres services AWS. CodeStar propose les services suivants :
- le dépôt de code Git CodeCommit ;
- CodeBuild pour l'automatisation du build et des tests ;
- CodePipeline pour l'intégration continue et la livraison continue (CI/CD) ; et
- CodeDeploy et CloudFormation pour le déploiement du code et de l'infrastructure.
CodeStar permet également de gérer les rôles et les politiques de sécurité via AWS Identity and Access Management, de sorte que les membres d’une l'équipe peuvent rejoindre un projet sans intervention majeure.
CodeStar n'est adapté que pour les projets sur AWS. Et cela est déterminant lorsqu’il est question de choisir entre l'achat et le développement de sa chaîne d'outils DevOps : les produits bien intégrés ne fonctionnent généralement que sur une plateforme ou que pour une méthodologie de développement particulière.
CodeStar n'est qu'un exemple parmi d'autres. Cloud Foundry en est un autre. Le PaaS open source est livré avec son outil de gestion de l'infrastructure BOSH pour maîtriser le versioning, le déploiement et la gestion du cycle de vie – cela comprend également la surveillance, la reprise après sinistre et les mises à jour de code. Les clients Microsoft peuvent de leur côté se tourner vers Azure App Service pour mettre en place un pipeline CI/CD à partir de Visual Studio Team Services (VSTS).
Une chaîne d'outils DevOps personnalisée
Les pipelines DevOps pré-intégrés ne sont pas complètement exclusifs et peuvent être couplés à d’autres outils de développement - habituellement Git et quelques IDE, comme Eclipse. AWS CodePipeline et CodeBuild peuvent par exemple utiliser GitHub pour la compilation, les tests et le déploiement du code. De même, CodeStar donne aux développeurs leur choix de l’IDE avec des connexions à Eclipse et Microsoft Visual Studio. Cela garantit que les changements de code sont automatiquement intégrés dans le projet CodeStar. De même, l'interface ouverte de VSTS repose sur des API REST, HTML, JavaScript et CSS pour se connecter à des logiciels tiers. Cette extensibilité a donné naissance à un écosystème autour de VSTS.
Lorsqu'une DSI crée son pipeline DevOps à partir de zéro, elle se tourne généralement vers un outil d’intégration continue (CI – Continuous Integration), comme Jenkins, Travis CI ou encore CircleCI. Pour raccorder des logiciels libres dans le pipeline CI/CD, il est nécessaire d’utiliser la méthode de l'outil CI pour connecter le référentiel de code au pipeline de build. Jenkins s'appuie par exemple sur des plug-ins ; Travis CI utilise de son côté un fichier de configuration YAML. Certaines entreprises préfèrent que toutes les modifications de code ou de build soient répercutées dans sur un canal de communication sociale, comme Slack ou Atlassian Hipchat – sous la forme de notifications. La connexion aux outils externes provient souvent de la plateforme CI, ce qui en fait un choix fondamental pour le reste du pipeline DevOps.
Enfin pour les entreprises qui ne souhaitent s’appuyer sur un Paas et ses outils, mais qui n'ont pas le temps ou l'expertise pour assembler plusieurs outils DevOps, il existe une autre option : les services managés. CloudHesive, iTMethods et TriNimbus en sont par exemple des fournisseurs. Ils proposent des environnements DevOps personnalisables et du support.
Comme dans toute décision IT, faire le choix d'une chaîne d'outils DevOps packagée ou sur mesure repose sur plusieurs facteurs : l'expertise de l’entreprise dans le déploiement de logiciels open source ; sa volonté de s'adapter à des processus définis ou celle de se laisser une liberté maximale dans la sélection et l'intégration d'outils ; et enfin son utilisation ou non de PaaS qui favorisent une méthodologie donnée.
