Le terme DevOps est apparu assez récemment dans le paysage informatique mondial, mais s’est déjà hissé au sommet des pratiques les plus efficaces. D’après le cabinet Gartner en 2015, 25% des 2000 plus grands groupes mondiaux s’orientaient vers la démarche DevOps. Plus qu’une méthode de travail, il s’agit surtout d’un changement culturel qui vise, comme son nom l’indique, à rapprocher le développement des opérations. L’objectif est double : raccourcir les délais de déploiement de mises à jour et garantir un haut niveau de qualité.
Le secret de la démarche réside dans la coopération et le partage ; les développeurs et les responsables de l’exploitation des systèmes collaborent pour délivrer le logiciel en continu. Les cycles de développement sont plus courts, la qualité est évaluée tout au long du projet et les déploiements sont plus fréquents.
« DevOps est un ensemble de pratiques et de valeurs culturelles qui a fait ses preuves pour aider les organisations de toutes tailles à améliorer leurs cycles de sortie de logiciels, leur qualité, la sécurité et la capacité à obtenir rapidement un feedback sur le développement. » — Puppet Labs, rapport «State of DevOps», 2017
BlueMind a choisi d’implémenter une démarche DevOps au travers du processus d’intégration continue. Focus sur les enjeux et bénéfices.
Un nouveau paradigme
Traditionnellement, les développeurs ne partageaient pas leur travail avec le reste de l’équipe et avançaient individuellement sur de longues périodes. Ils n’intégraient leurs modifications au code qu’une fois leur travail terminé. Le développeur n’avait pas de vision sur l’impact réel d’une mise à jour sur l’ensemble de l’application. En conséquence, on ne peut identifier les problèmes qu’en bout de chaîne et il est difficile de les localiser précisément, retardant la livraison des mises à jour.
De leur côté, les directions opérationnelles doivent attendre parfois plusieurs mois que les tests et le déploiement soient enfin satisfaisants pour répondre à un besoin utilisateur… qui a probablement déjà évolué. Les deux équipes, développement et opérations ne partagent pas les mêmes objectifs et donc n’ont pas les mêmes priorités.
Sur le papier les exigences du logiciel sont claires, définies à l’avance et stables. Les développeurs s’occupent du code, les équipes opérationnelles de sa mise en œuvre sur les systèmes de l’entreprise. Sur le papier…
Dans le monde réel l’informatique évolue trop rapidement pour permettre de conserver un cahier des charges fixe tout au long du projet. Dans le cadre d’un éditeur de logiciel, le « projet » ne se termine jamais ! Les logiciels doivent pouvoir être mis sur le marché plus rapidement, mais ils doivent aussi pouvoir évoluer constamment. De nouvelles fonctions doivent pouvoir être ajoutées le plus simplement possible, et les bugs découverts doivent pouvoir être corrigés. Les nouveautés ne doivent pas casser l’existant et prendre en compte toutes les configurations et cas possibles. Il n’y a plus de jour «J » pour délivrer le produit comme auparavant.
DevOps et ses pratiques (dont l’innovation continue) visent à mettre fin à cette bataille entre Dev et Ops – pour parvenir à l’équilibre entre innovation et stabilité.
DevOps : un meilleur dialogue entre les équipes
La démarche DevOps consiste à mettre en place un processus global impliquant tous les intéressés quel que soit leur rôle initial. Fini les individus isolés et hyper-spécialisés, les équipes de développement et d’exploitation travaillent en commun sur tout le cycle de vie d’une application, de sa conception et son test jusqu’à son déploiement et à son exploitation.
Les équipes partagent de nombreuses responsabilités et combinent leurs workflows. Cela leur permet de limiter les pertes d’efficacité et de gagner du temps.
Dominique Eav – Chef d’orchestre de la qualité BlueMind
« Chez BlueMind personne n’avance seul dans son coin. Nous cultivons la collaboration et le partage pour favoriser l’efficacité opérationnelle. Nous avons un objectif commun et un plan – défendu par le product ou feature owner – pour l’atteindre ensemble. Toute l’équipe peut suivre les projets, les idées et les difficultés de chacun. »
Ce temps passé à partager les savoir-faire, idées et connaissances doit être largement rentabilisé par l’efficacité gagnée dans la qualité des livraisons, l’anticipation des problèmes/erreurs et la rapidité des dépannages.
Intégrer en continu
Expliquée simplement, l’intégration consiste à rassembler des morceaux de code et à les faire fonctionner ensemble. Souvent, c’est un vrai sacerdoce ! En effet, les projets et les environnements sont nombreux, chaque environnement impliquant une organisation différente du module concerné, des étapes de construction, de test, de validation et de déploiement. L’intégration continue permet de résoudre ces problèmes en faisant collaborer tous les acteurs d’un projet du développement à l’exploitation.
L’intégration continue désigne l’ensemble des pratiques qui permettent aux développeurs d’intégrer régulièrement leurs modifications de code à un référentiel centralisé, de créer et mener automatiquement des sessions de test automatisés, puis de déployer les résultats du build si les voyants sont au vert. Ce processus permet de repérer et corriger plus rapidement les bugs, d’améliorer la qualité et de réduire les temps de validation et de publication de nouvelles mises à jour.
Historique des résultats de tests.
Pour un test donné on voit ce qu’il se passe maintenant et l’historique, un FAIL sur un test qui passait auparavant est signe d’une régression
Elle permet de vérifier, à chaque modification du code source, que le résultat ne produit pas de régression ou de défaut dans les parties non modifiées de l’application. Les bugs sont identifiés et donc corrigés plus rapidement, les temps de validation et de publication sont réduits et bien entendu la qualité finale est améliorée.
« Nous utilisons largement le principe de pull request. Il s’agit d’un mécanisme permettant à un développeur de partager et valider son travail sans qu’il ne soit forcément terminé. Le développeur peut proposer à tout moment une pull request pour solliciter une revue des personnes impliquées. C’est beaucoup plus qu’une simple validation – il s’agit d’une vraie discussion sur les partis pris techniques de la fonctionnalité proposée. Ainsi nous nous assurons d’une part que l’ensemble de l’équipe puisse suivre les évolutions techniques et d’autre part de l’intégrité des choix »
— Dominique Eav responsable qualité BlueMind.
Tableau de bord sur le build d’une branche (master)
Ce diagramme présente les résultats de tests, les différentes étapes du build et les builds précédents
L’automatisation : clé de voûte de l’intégration continue
Compilation, tests unitaires et fonctionnels, validation produit, tests de performance… sont des activités essentielles mais chronophages, sans parler de l’erreur humaine, toujours possible. Le principe de l’intégration continue repose sur leur automatisation pour gagner du temps et assurer toujours le meilleur niveau de qualité possible.
Ainsi, dès que le développeur produit du code, l’outil vérifie automatiquement qu’il respecte les règles communes mises en place pour l’ensemble de l’équipe. Cette procédure garantit la qualité du code produit et sa stabilité dans le temps par le respect des bonnes pratiques de développement.
Cet outil d’analyse du code permet de voir la couverture de test sur le code. Il faut tendre vers la plus grande couverture possible.
BlueMind utilise Jenkins pour piloter sa chaîne d’intégration continue. Ce logiciel permet de tester et de rapporter les changements effectués sur une large base de code en temps réel pour détecter rapidement les problèmes.
Jenkins nous permet de construire et tester nos branches de développement (features ou corrections), dont les changements intègrent en continu nos branches de release (3.0, 3.5, 4.0), et ce sur toutes les distributions linux supportées (8 pour BlueMind 3.5.9). Le coeur de BlueMind comprend plus de 500 modules, et interagit avec de nombreux AddOns que l’on retrouve sur le Marketplace, eux aussi construits, testés et déployés par notre chaîne d’intégration continue, avec les mêmes contraintes de compatibilité et de qualité. Plus de 3000 tests sont réalisés sur chaque build. Ce degré de complexité serait impossible à gérer manuellement ! Toute l’intelligence de l’intégration continue réside dans l’enchaînement automatique des différentes tâches, dans une logique d’industrialisation des processus.
« Nous avons une approche consensuelle et pragmatique. Nous mettons en œuvre et améliorons nos processus de façon à faciliter la vie des membres de l’équipe, pas pour répondre à un cahier des charges qui nous serait imposé. L’automatisation qui en résulte permet d’aller vite et de faire émerger les éventuels problèmes au plus tôt. Chaque brique de notre chaîne d’intégration continue est une ceinture de sécurité »
— Dominique Eav responsable qualité BlueMind.
Cet outil d’analyse statique de code qui examine les différentes classes, mesure la dette technique c’est à dire le temps nécessaire pour corriger les problèmes que présente telle ou telle partie du code.
En plus de supprimer des tâches fastidieuses, cette automatisation permet de fiabiliser le processus de déploiement tout en augmentant la fréquence des livraisons. Les équipes peuvent se consacrer à améliorer les fonctions existantes ou assurer un suivi de qualité plutôt que d’effectuer des tests manuellement.
Des bénéfices concrets
L’intégration continue fait gagner énormément de temps aux équipes de développement puisque chaque modification du logiciel est immédiatement testée. Un code compilé régulièrement permet d’identifier rapidement les modifications qui posent problème en cas d’erreur. Le développeur a un aperçu rapide des régressions qu’il a causé. Les incompatibilités entre le logiciel et l’écosystème dans lequel il devra évoluer sont elles aussi repérées très tôt.
Durant tout le processus de développement et de déploiement, toute l’équipe collabore étroitement dans un but commun : la réussite du projet dans son intégralité, et pas uniquement de leur partie.
Lorsque toute l’équipe de projet est agile, le développement d’une nouvelle fonctionnalité ou la correction d’un bug peuvent être rapidement mis en production – ou annulés si nécessaire. Une version fonctionnelle du logiciel est toujours disponible et il n’est pas utile d’attendre que le logiciel soit mis en production pour s’apercevoir qu’il ne fonctionne pas. Dans le cas de BlueMind, nous mettons d’abord ces nouvelles fonctionnalités ou correctifs en production en interne. Un procédé que l’on appelle « eating your own dog food« , ce qui signifie que nous sommes les premiers utilisateurs de notre solution.
Côté client, l’intégration continue permet de livrer plus rapidement et plus fréquemment des mises à jour tout en garantissant le plus haut niveau de qualité possible.
Pour conclure
Installer un ordonnanceur comme Jenkins n’est pas suffisant pour faire de l’intégration continue. Comme le stipule le Manifesto de l’Agilité logicielle, les individus et les interactions passent avant les processus et les outils. Une démarche DevOps relève donc de la responsabilité de tous. La culture DevOps implique d’adopter une approche transparente basée sur la communication et la collaboration entre les équipes informatiques/opérationnelles et de développement. DevOps est une excellente approche pour les entreprises qui innovent sans cesse !
BlueMind s’est structurée dès le départ autour de ces principes pour assurer le meilleur niveau de qualité dans un environnement complexe. Grâce à cette agilité nous pouvons livrer des produits stables et performants à travers des processus industrialisés entre exploitation et développement.