Comment obtenir de bons résultats avec DevOps

DevOps exige un changement de culture

L'idée est de permettre aux services IT de tester et de publier plus rapidement des mises à jour et de nouveaux produits, en recourant davantage aux outils d'automatisation et de surveillance. Avec l'émergence de DevOps, les fournisseurs fabriquent à la chaîne différents produits pour faciliter ce fonctionnement agile, mais John Fredrickson met en garde contre l'achat d'un trop grand nombre d'outils.

« Le défi principal n'est pas vraiment une question technique, c'est plutôt une question de communication. Si nous arrivons à renforcer la communication et la collaboration entre les différents intervenants, la technologie semble fonctionner ».

« En matière d'automatisation et de mise à disposition, la panoplie technologique est fournie : on peut presque dire qu'un nouvel outil DevOps sort chaque semaine. Les individus et les équipes sont le facteur constant. Si nous arrivons à faire en sorte que les gens partagent leurs idées et analysent ce qui fonctionne, alors, c'est là que DevOps », ajoute-t-il.

Généralement, la mise à disposition de technologies souffre surtout des changements d'équipes. Un projet de mise à jour peut demander l'intervention de plusieurs équipes. Certaines sont « très innovantes », d'autres travaillent différemment. Tout cela allonge le cycle de développement, ce qui n'est pas vraiment compatible avec une mise à disposition rapide.

Comment faire ? « Il n'y a pas de recette miracle » affirme John Fredrickson.

Des compétences qui se payent

Un autre défi consiste à attirer les personnes ayant les compétences adaptées. « Le recrutement est l'un des problèmes de l'univers DevOps. Et je ne suis pas sûr que nous en ayons fait complètement le tour. Si vous mentionnez DevOps, vous pouvez augmenter les salaires de 20 %. Retenir et recruter les bonnes personnes peut s'avérer complexe » dit John Fredrickson.

Chez Sky, tout le monde doit être impliqué dans le processus. « Nos systèmes communiquent : si nous sortons une fonctionnalité dans un système, les personnes sont également obligées de se parler » dit-il. Dans cette optique, Sky a commencé à diffuser largement dans l'entreprise un ensemble d'environnements sur lesquels il fournit des services de partage des idées et des innovations. « Cela peut nous pousser à accélérer le rythme » affirme J. Fredrickson.

Développement et exploitation mélangés au sein de DevOps

British Gas Connected Homes est un autre exemple d'entreprise ayant adopté DevOps. L'entreprise, qui fonctionne sous de nombreux aspects comme une startup, est une unité entièrement autonome de son parent, British Gas.

Connected Homes a une structure complexe, une gamme de produits avec différents niveaux de maturité et des équipes produit qui travaillent sur des sites dispersés au Royaume-Uni.

Au début, lorsque DevOps a été adopté, Connected Homes a constitué une équipe DevOps centralisée pour tous ses produits. Mais les différents niveaux de maturité et la diversité des technologies ont fait obstacle à l'objectif, explique Chris Livermore, responsable de l'exploitation.

Maintenant, à la place, Chris Livermore a intégré une quinzaine d'ingénieurs DevOps aux différentes équipes. Pour lui, DevOps se définit comme la collaboration entre les développeurs et les opérationnels. « Vous savez que vous faites du DevOps lorsque vous avez une équipe DevOps hybride » explique-t-il.

 « Si vous avez une équipe chargée des opérations et une autre chargée du développement, avec, entre les deux, une équipe DevOps, vous avez loupé quelque chose » ajoute-t-il, tout en reconnaissant qu'il peut s'agir d'une étape transitoire avant de passer au « DevOps intégral ».

« J'aime voir nos ingénieurs chargés des opérations participer au cycle de vie complet des logiciels. Leur opinion sur la conception et l'architecture des logiciels est tout aussi légitime que celle des architectes et des développeurs » explique Chris Livermore.

Il ajoute qu'il existe une ligne de démarcation nette entre ce qu'il attend du développeur chargé des technologies et de celui chargé des opérations : « Dans mon domaine, le développeur est responsable du code, et ces deux équipes collaborent pour créer la solution. Les personnes doivent être mobiles ; l'équipe de développement a besoin de comprendre les opérations et les opérationnels ont besoin de comprendre le développement. »

Automatisation du changement

Souvent long et laborieux, le traitement des changements implique différents niveaux d'approbation. Mais si les entreprises veulent être compétitives et sortir rapidement de nouvelles fonctionnalités et des mises à jour, l'effort en vaut la peine.

« La gestion du risque du contrôle des changements est l'une de mes bêtes noires » confie Chris Livermore, en ajoutant qu'il déteste les formulaires de demande de changement. « Je refuse absolument de renseigner ce type de formulaire. Ils n'ont pas leur place dans un univers de déploiement et de test automatisés ».

« Selon moi, le changement se produit pendant les phases de développement et de conception. Publier un code devrait être une formalité. Mais le contrôle du changement doit intervenir au bon moment du processus, et c'est là toute la difficulté. Le développeur ne devrait même pas travailler sur une fonctionnalité qui n'a pas encore été approuvée. C'est donc là que doit intervenir le contrôle du changement. »

Lorsque quelque chose ne fonctionne pas, la tentation est grande, d'après lui, de vite revenir dans notre zone de confort et d'ajouter quelques couches de procédures.

Chez Connected Homes, certains des produits les plus avancés sont liés à des processus de changement automatisés, notamment ceux dont la mise à disposition est entièrement intégrée et continue. La date et la fréquence des publications dépendent entièrement des propriétaires des produits, explique le responsable, mais l'exécution de la publication est automatisée.

Pour les produits moins avancés, non automatisés, Connected Homes a un centre de test en Inde. « Mais, d'après mes calculs, environ 20 % de ce temps est consacré à l'automatisation des tests. Ainsi, pour chaque publication, l'idée est de passer moins de temps sur les tests manuels et de développer l'automatisation ».

Chez Sky, la ligne de conduite est « de rester en bon rapport avec nos collègues de la gestion du changement. Certaines de nos équipes sont ravies du système de déploiement continu et apprécient de montrer ce qu'elles font et comment. Et, si tout va bien, elles obtiennent que vous n'ayez pas à suivre un processus, car il est intégré. »

Sky a démarré par un compromis : les équipes qui font des changements mineurs auront l'approbation pour le faire et ajusteront la demande en cas de changement important. « C'est une petite victoire, mais on ne peut pas gagner sur tous les plans » affirme-t-il.

Rendre DevOps fonctionnel : une histoire au long cours

Choisir la voie DevOps exige de l'endurance, de la détermination et, par-dessus tout, d'embarquer le service IT dans l'aventure.

Pour John Fredrickson, le fait d'accélérer et de mettre en libre-service des processus chronophages – comme les pare-feu et certains changements de DNS (Domain Name System), auparavant basés sur des processus – représente un gain véritable, très apprécié.

« Cherchez où vous pouvez limiter les frictions dans l'entreprise et réfléchissez à la manière de mettre en place des processus en libre-service et plus rapides » conclut-il.