Opinions

Les huit erreurs à éviter pour réussir votre démarche DevOps

Par La rédaction, publié le 24 mai 2013

Si le DevOps peut offrir un avantage compétitif incontestable pour les organisations IT, sa mise en oeuvre un certain nombre de bonnes pratiques.

Qu’est-ce que le DevOps ? Un nouveau mot à la mode qui fait le buzz ? Le DevOps, c’est surtout une démarche qui donne de la valeur ajoutée, plus rapidement et avec une fiabilité optimale. C’est un avantage compétitif incontestable pour les organisations IT. J’ai observé bien souvent qu’en essayant d’innover en introduisant de nouvelles pratiques, les organisations obtiennent un effet inverse : l’efficacité de la valeur ajoutée est diminuée. Malgré tout, certaines pratiques sont incontournables et toute organisation IT doit les mettre en œuvre et les respecter. Certaines de ces bonnes pratiques peuvent paraître évidentes. L’expérience m’a appris que certaines d’entre elles sont totalement négligées. L’omission de ces pratiques essentielles et fondamentales peut aboutir à des cycles terriblement longs et entraîner des ralentissements dans les flux de releases, ce qui bien sûr va à l’encontre des objectifs du DevOps.

1. La montée en charge n’a pas été prévue. Lorsque vous démarrez une démarche de rapprochement du développement et de la production, vous devez penser à long terme et créer des processus capables de résister à une montée en charge. Avoir une seule personne pour approuver l’ensemble des changements d’un processus automatisé est un exemple de processus ne résistant pas à une montée en charge. Vous vous exposez à des goulots d’étranglement. Cela peut marcher si vous produisez seulement quelques releases par an, mais supposons que vous passiez à plusieurs par semaine : la solution n’est pas viable.

Si votre démarche réussit, la montée en charge interviendra à une vitesse que vous n’avez même pas imaginée. Elle doit être planifiée dès le début. Ne pas le faire est une erreur fondamentale. Autrement dit, même si cela marche lorsque la charge de travail gérée par le système est modérée, les processus impliqués seront confrontés à un goulot d’étranglement si aucune montée en charge n’est possible. Ceux qui s’étaient ralliés à votre cause seront très vite déçus, et votre initiative DevOps sera perçue comme une démarche valable uniquement pour les petites équipes.

2. Le code n’est pas capable de faire face à des releases fréquentes. La deuxième erreur concerne le code et peut se manifester dans des projets utilisant les technologies les plus récentes. Trop souvent, un petit nombre de fichiers doit être travaillé et retravaillé à plusieurs reprises. Cela peut provoquer d’importants problèmes de fusions et générer des pertes de temps journalières. Le refactoring est indispensable pour aller de l’avant à ce stade.

Si vous avez l’habitude d’entendre des plaintes telles que « Je ne peux pas faire cette modification car cela va avoir des répercussions sur x, y, z et cela va prendre des semaines ou des mois », c’est que votre code a un problème dont la solution possible est le refactoring. Les personnes concernées par la fonctionnalité ou le produit à refactorer doivent être impliquées ; le changement nécessaire peut prendre du temps et n’est pas sans risque, même si le risque peut être limité par le recours à des tests unitaires.

3. Absence de tests unitaires. J’ai souvent été surpris de voir des équipes faire de l’intégration continue (CI ou Continuous Integration) sans recourir à des tests unitaires. Un build issu de l’intégration continue prouve uniquement que votre code se compile correctement. Si vous ne faites pas de tests unitaires, vos tests système automatisés ne prouvent rien. Par ailleurs, si vous faites tester manuellement un build n’ayant jamais subi aucun test unitaire, vous perdez du temps et des ressources précieuses.

4. Des tests automatisés non conçus pour résister à la montée en charge. L’un des problèmes fréquemment rencontrés avec les tests automatisés est le temps bien trop long que prend l’exécution des séries de tests. Même des personnes expérimentées créent des cas de test qui dépendent des résultats d’autres tests, or ils ne résistent pas à la montée en charge. Des cas de tests qui auparavant s’exécutaient en quelques minutes prennent plusieurs heures et au fur et à mesure que la couverture de code s’effectue, c’est-à-dire tout au long du cycle.

Heureusement, de nombreux cas de tests peuvent être écrits afin de ne pas dépendre de l’état de précédents tests. Même si cela n’est pas toujours possible, les tests ne devraient pas être interdépendants. Lorsqu’ils sont réalisés dans le cadre d’un environnement virtualisé, nombre d’entre eux peuvent être exécutés en parallèle (les tests sont exécutés sur différentes machines, chacune correspondant à un environnement particulier). Vous obtenez ainsi des gains de temps considérables et la montée en charge de votre solution DevOps s’effectue plus facilement.

5. Une capacité insuffisante. La virtualisation, y compris l’utilisation du cloud public, peut fournir suffisamment de capacité pour combler les besoins des équipes de développement. Toutefois, la R&D et le QA se plaignent souvent d’un manque de capacité. Les machines virtuelles (VM) peuvent être créées si facilement qu’elles le sont sans trop de réflexion. Malheureusement, les VM sont rarement détruites dès qu’elles cessent d’être utilisées, ce qui affecte leur capacité et nuit aux performances.

Pensez à faire le ménage. Utilisez un système d’automatisation qui permet de détruire les VM ou de les restaurer en image vierge et fermez la session dès que la VM n’est plus utilisée. Une pratique très courante consiste à détruire la VM ou la restaurer en image vierge dès que les tests de QA ont été effectués avec succès. En cas d’échec des tests, vous laissez tourner la VM ou gardez l’image de la VM jusqu’à ce que vous trouviez une solution.

6. Une utilisation inefficace des ressources. La réplication automatique des VM est utile. C’est encore plus utile si chaque VM est correctement configurée et que la dernière release est copiée sur le système. Des outils automatisés de déploiement tels que « Puppet and Chef » garantissent que la VM de base est configurée de façon appropriée. L’automatisation du déploiement d’applications vous permet de garantir ensuite que la dernière release est installée sur l’environnement nouvellement créé.

7. Ne pas utiliser un seul ensemble de processus de déploiement pour tous les environnements. Comment les logiciels développés par votre équipe peuvent-ils être déployés sur tous les environnements ? Des scripts de déploiement personnalisés pour chaque environnement ne vous seront d’aucune utilité. Il est nécessaire d’exécuter le même processus de déploiement encore et encore. Afin qu’au moment de l’arrivée du produit en production, le processus de déploiement ait été exécuté maintes fois.

Le déploiement basé sur le modèle est un élément clé de cette démarche. Le modèle d’application doit tenir compte de l’environnement sur lequel il est déployé. Ainsi, les valeurs appropriées sont incluses dans la configuration de déploiement pour laquelle l’environnement est déployé. Résultat final : au moment où une application est déployée en production, le modèle de déploiement d’application a été testé plusieurs fois.

8. Ne pas savoir quoi, quand, où, qui et comment. Un système d’intégration continue tel que Jenkins peut être utilisé pour réaliser un build, dupliquer des environnements, déployer des logiciels et exécuter des tests pour chaque environnement. Toutefois, ce type de système concerne à l’origine des builds et des déploiements à petite échelle.

Le problème avec ce niveau d’automatisation et de libre-service ce sont les questions restées sans réponse. Comment savoir quel build a été déployé et où ? Que contient le build ? Où sont les résultats des tests ? Plusieurs autres questions peuvent se poser, la plupart d’entre elles relatives à l’utilisation des données produites par un grand nombre de builds, de déploiements et de tests, tous potentiellement exécutés avec différents outils.

Le suivi de ces informations s’effectue plus facilement quand on dispose d’un modèle de processus métier de niveau supérieur. Il facilite également la prise de décisions. Si vous ajoutez une couche supplémentaire ayant pour rôle d’orchestrer les processus métier et que vous utilisez le processus de niveau supérieur pour exécuter le build, vous vous dotez de moyens performants. Il est alors possible de commencer le déploiement, d’exécuter des tests et de rassembler et traiter des informations sur le passage en production de chaque build. Les audits peuvent ensuite être réalisés plus facilement. Les équipes Développement, QA et Production travaillent toutes sur un ensemble de données commun. A partir de ces données, tous les membres de l’équipe peuvent consulter les détails d’une release et suivre la gestion des changements tout au long du processus.

En conclusion, l’automatisation, l’automatisation, l’automatisation est essentielle pour réussir une démarche DevOps ; elle réduit la durée des cycles et permet de livrer plus rapidement les produits aux clients. Toutefois, si les processus ne sont pas bien gérés, et sans l’implémentation d’un framework de reporting correct, la quantité de releases à livrer peut devenir rapidement difficile à gérer. La mise en place d’une couche d’orchestration des processus permet de générer des rapports tout au long du cycle de vie de la release. Vous disposez ainsi de métriques mettant en valeur les résultats positifs de votre initiative DevOps par rapport à vos objectifs.