Conseils et exemples pour réussir la mise en place de DevOps en entreprise

Equipe DevOps

Ce n'est pas parce que votre intitulé de poste contient « DevOps » que vous êtes un développeur formé aux processus opérationnels, ni un opérationnel qui sait écrire du code. En fait, DevOps désigne un membre d'une équipe transversale, « où chacun est responsable de tout » explique Paul Biggar, fondateur de CircleCI, prestataire de déploiement et d'intégration continus.

En pratique, les entreprises ne passent pas radicalement à la structure DevOps, constate Abner Germanow, directeur de la stratégie d'entreprise chez New Relic. Au sein de l'entreprise, rare est l'entité qui se décrit comme un groupe DevOps à 100 %. On trouve plutôt une équipe DevOps correspondant à des applications précises, comme l'équipe mobile ou l'équipe de validation, ajoute-t-il.

Chez Red Hat, le projet interne DevOps « Team Inception » a pris la forme suivante : un chef d'équipe, un responsable du produit et un scrum master, auxquels s'ajoutent quatre ingénieurs compétents en administration système, en sécurité de l'information, en développement et en mise en production. « En fait, comme chacun possédait au moins deux de ces compétences, il y avait assez de synergie pour collaborer très rapidement » raconte Steve Milner, ingénieur IT chez Red Hat et membre de la Team Inception.

Côté développement

Le développement a donné ses premières lettres au terme DevOps : en toute logique, la méthodologie de développement constitue une pierre angulaire de l'environnement DevOps. En l'occurrence, il s'agit d'une méthode agile. « DevOps sans développement agile n'aurait aucun sens, explique Evan Powell, directeur général de StackStorm, une startup DevOps. Si vous ne déployez pas le code rapidement, peu importe que son exploitation soit agile ou pas. »

Pour beaucoup de groupes, la première étape consiste donc à choisir une méthode de développement agile, souvent Scrum ou Kanban, pour aider les équipes de développement logiciel à définir les buts et les priorités, à assigner les tâches et à repérer à quel moment du cycle de développement les problèmes se produisent.

L'intégration et la livraison continues (ou le déploiement continu) forment un autre pilier de DevOps. L'intégration continue consiste à effectuer automatiquement et en permanence des tests sur une branche de code, alors que la livraison continue automatise le processus de mise en production du code après les tests et la validation.

« Autrefois, on ne mettait le code en production qu'à des moments précis et en heures creuses », raconte Brian Doll, vice-président de la stratégie de GitHub, éditeur d'une plateforme référentielle de code source. Mais cet ancien modèle de cycles de déploiement orchestrés est « l'antithèse de DevOps », ajoute-t-il. « L'objectif est l'automatisation du cycle de déploiement ».

Le code en lui-même est stocké dans un référentiel de code source à des fins de sauvegarde et de contrôle de version. Actuellement, ce référentiel repose le plus souvent sur le logiciel libre Git, comme c'est le cas de GitHub ou d'Atlassian BitBucket.

Les référentiels de code issus de Git ont remporté la bataille face aux anciens systèmes de contrôle de version tels que Concurrent Versions System (CVS) ou Apache Subversion. Ecrit à l'origine par Linus Torvalds, le développeur de Linux, Git répond au besoin de la communauté open source d'un système de contrôle de version décentralisé et capable de prendre en charge des équipes de développement éparpillées dans le monde entier.

« Ce modèle décentralisé fonctionne bien en entreprise où l'on rencontre de grandes équipes mondiales relativement informelles » affirme Brian Doll. Les versions commerciales de Git incluent des fonctionnalités de collaboration, ainsi que des approbations et des workflows basés sur des règles. De plus, elles prennent en charge des outils largement répandus : environnements de développement intégré (IDE, Integrated Development Environment), intégration continue/développement continu et outils de test.

L'infrastructure sous forme de code

Les référentiels ne contiennent pas que du code. Ils stockent également de plus en plus souvent des modèles et des scripts détaillés de configuration créés à l'aide d'outils de gestion de configuration comme Puppet et Chef, deux des langages les plus fréquents dans les référentiels GitHub, selon Brian Doll.

L'automatisation de la configuration et du déploiement de l'infrastructure a engendré la notion d'« infrastructure sous forme de code ». Par exemple, Rally Software, éditeur de logiciels de gestion de projet agile, a passé les 18 derniers mois à créer des recettes Chef pour ses services de base, répartis sur 60 hôtes VMware et instances AWS (Amazon Web Services).

« Autrefois, on configurait tout à la main mais c'est difficile en cas d'évolution rapide, constate Jonathan Chauncey, ingénieur logiciel chez l'éditeur. Cette méthode s'est aussi révélée problématique pour le débogage de problèmes touchant toute une pile de serveurs. »

Comme les ingénieurs de Rally possédaient déjà de sérieuses compétences en programmation Ruby, l'éditeur s'est tourné vers l'outil de gestion de configuration Chef qui lui apporte, dit-il, une méthode cohérente et reproductible d'installation de logiciels. De fait, il est favorable à la création de modèles pour tous les systèmes, et pas uniquement pour les microservices et les services Web évolutifs.

« L'infrastructure ne doit pas s’appuyer sur des bons sentiments. Si votre infrastructure rend l'âme à deux heures du matin et que vous devez la reconstruire, pouvez-vous vraiment compter sur votre équipe pour s'y atteler en pleine nuit ? »

Qui plus est, sous forme de code, l'infrastructure s'intègre aux autres processus DevOps, c'est-à-dire les tests et le déploiement. Rally stocke toutes ses recettes d'infrastructure dans son référentiel GitHub. Elles sont testées et déployées dans le cadre des mêmes processus d'intégration et de déploiement continus dont l'exécution plusieurs dizaines de fois par jour livre des fonctionnalités logicielles. « Quelle que soit la modification, qu'il s'agisse du code logiciel ou de l'infrastructure, on utilise le même processus » explique Jonathan Chauncey.

L’« infrastructure sous forme de code » jouit d'un autre atout : vos systèmes ne vieillissent pas puisque rien n'est plus facile que de les tenir à jour des dernières versions et packages, ajoute Alain Gaeremynck, responsable de l'architecture d'entreprise du groupe canadien Pages Jaunes et manager DevOps.

Alain Gaeremynck l'affirme : « nous sommes favorables à l'infrastructure sous forme de code et à l'"infrastructure jetable". Au lieu de construire notre infrastructure une fois puis de la surveiller et d'en assurer la maintenance consciencieusement, nous détruisons tout pour le reconstruire à chaque fois [que nous sortons une nouvelle version]. »

Dans un processus de build, « il est facile de glisser des mises à jour de Java ou le dernier système d'exploitation par exemple, puisque de toute façon la phase suivante est l'assurance qualité ».

Et le Cloud ?

Mais est-ce que DevOps a quelque chose à voir avec le Cloud ? Pour certains, l'accès à une infrastructure Cloud sur laquelle demander et provisionner des ressources fait partie intégrante de DevOps.

« A mon avis, l'aptitude à consommer des ressources selon les besoins et à dissocier l'infrastructure du service principal constitue un préalable à DevOps » affirme Ram Akuka, directeur DevOps chez Deutsche Telekom HBS, prestataire de téléphonie pour les PME.

Le Cloud n'est pas obligatoirement celui d'AWS, ni même un Cloud public. Si Deutsche Telekom utilise AWS pour les ressources de développement, l'entreprise a également bâti un Cloud privé basé sur Citrix CloudStack et VMware pour son environnement de production. L'environnement est complété par Jenkins pour l'intégration continue, des scripts sur mesure, des recettes Chef stockées dans GitHub et des services de Ravello permettant de créer des bacs à sable de production pour les développeurs sur AWS. « Cette solution nous convient bien » conclut Ram Akuka.

Toutefois, les entreprises qui se lancent dans DevOps doivent gérer une infrastructure installée qui ne s'accorde pas toujours avec les outils modernes d'automatisation d'infrastructure… et encore moins avec les piles de gestion d'un Cloud privé.

Certains acteurs de l'automatisation d'infrastructure comme QualiSystems ou CFengine se vantent de leur capacité à gérer l'infrastructure installée que leurs concurrents comme OpenStack ne prennent pas encore en charge, si tant est qu'ils le fassent un jour. « CFengine peut automatiser tout ce qui accepte un agent intégré, explique Mahesh Kumar, vice-président du marketing de CFengine. Peut-être devrons-nous compiler un agent pour telle ou telle plateforme si nous ne l'avons pas, mais nous pouvons l'adapter. »

Evan Powell de StackStorm a vu d'ingénieuses solutions pour contourner le problème d'une infrastructure héritée : un groupe DevOps a même écrit une couche d'API pour convertir certaines actions. « Ainsi, qu'importe si vous avez une vieille solution EMC aux liaisons limitées. On garde l'existant, mais avec un petit lifting pour le rendre compatible DevOps » conclut-il.