DevOps et Intégration continue : focus sur la démarche qualité de BlueMind

BlueMind a intégré le mouvement DevOps dans sa démarche qualité. Grâce à l’intégration continue nous produisons plus rapidement et de meilleure qualité.

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.

Suivez nous :

Supervision d’une installation BlueMind

Lorsque une panne se produit ou que des dysfonctionnements sont constatés, il est souvent complexe d’en trouver la cause. Voilà pourquoi BlueMind 3.5.9 intègre désormais un stack complet (et open source) de métriques, alerting et de visualisation de l’état de la plateforme.

Un système BlueMind ou un serveur de messagerie en général est un système complexe. Il intègre de nombreux composants avec des rôles bien définis mais parfois obscurs. Lorsque une panne se produit ou que des dysfonctionnements sont constatés, il est souvent complexe d’en trouver la cause.

Une panne du système de messagerie est souvent source de panique car le service est critique pour la majorité des utilisateurs. Des mesures d’urgence sont alors prises, qui conduisent souvent à des redémarrages qui solutionnent (parfois) le problème mais vont rendre l’analyse post-mortem particulièrement complexe.

L’existant

Un système BlueMind, composé de nombreux services et de nombreuses machine virtuelles Java, essaie le plus souvent de ne pas mourir en silence.

On va trouver :
• Des fichiers /var/log/java_pid1234.hprof ; des dumps mémoires générés automatiquement lorsque le système rencontre un manque de mémoire
• Des fichiers de logs, très nombreux, où l’on va trouver des vilaines choses comme des index elastiscsearch qui nous disent « disk high watermark reached, disabling shards » (le disque dur est plein)

Dans ces différents cas, le problème ne sera pas pris en compte tout de suite, et un redémarrage ou un nettoyage du disque va avoir lieu avant qu’une anomalie ne soit remontée pour analyse.

Laisser un disque dur se remplir quand on gère un système n’est pas un fait d’arme très glorieux. On arrive à la situation suivante : l’administrateur système nettoie le disque dur, puis déclare une anomalie pour indiquer que la recherche n’est plus fonctionnelle.

Ce petit mensonge est problématique, mais ce qui nous intéresse, c’est d’empêcher la situation de se produire.

La supervision

Les systèmes de supervision existent, mais leur déploiement était jusqu’à maintenant laissé à la charge des personnes supervisant des installations BlueMind. La supervision des systèmes Java est un sujet assez complexe et les métriques généralistes ne sont ni intéressantes ni parlantes.

Avec BlueMind 3.5.9, nous avons intégré un stack complet de métriques, alerting et de visualisation de l’état de la plateforme.
Notre ADN étant open-source, nous nous sommes tournés vers une solution open-source : la TICK stack (Telegraf, Influxdb, Chronograf, Kapacitor) http://influxdata.com. Un agent telegraf est installé sur chaque nœud de votre installation. Telegraf transmet ces données à Influxdb, Kapacitor les analyse pour produire des alertes et Chronograf affiche des tableaux de bord pour aider à anticiper les problèmes.

Notre intégration

Pour la 3.5.9 toute la stack est disponible mais n’est pas déployée par défaut. Sur un serveur (votre serveur principal, avec bm-core, ou un serveur de supervision dédié) il faut installer le paquet bm-tick-full.

Ce dernier va déployer toute la stack TICK (que nous avons intégré dans nos dépôts pour contrôler les versions utilisées). Sur chaque serveur de votre installation BlueMind, il faut installer bm-tick-node. Si vous faites cela avant le passage en 3.5.9, l’assistant de mise à jour va s’occuper de tout. Sinon il est préférable après redémarrage de forcer la configuration de toute la stack :

curl -H « X-Bm-ApiKey: $(cat /etc/bm/bm-core.tok) » -XPOST http://localhost:8090/internal-api/tick/mgmt/_reconfigure

depuis votre serveur bm-core.

Agent Java

Les administrateurs les plus attentifs vont remarquer que les processus Java de BlueMind sont lancés avec une option supplémentaire :

/usr/lib/jvm/bm-jdk/bin/java -Dlogback.configurationFile=/etc/bm/local/bm-core.log.xml -Dio.netty.native.workdir=/var/lib/bm-core/work -Xloggc:/var/log/garbage-collector/bm-core/gc.pause.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=4 -XX:GCLogFileSize=4M -XX:+PrintGCApplicationStoppedTime -server -Xms812m -Xmx812m -Xss256k -XX:+UseCompressedOops -XX:MaxDirectMemorySize=812m -XX:+UseG1GC -XX:MaxGCPauseMillis=500 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/log -Djava.net.preferIPv4Stack=true -Dnet.bluemind.property.product=bm-core -javaagent:/var/lib/bm-metrics-agent/bm-metrics-agent.jar -Djava.awt.headless=true -Dosgi.noShutdown=true -Duser.timezone=GMT -cp /usr/share/bm-core/plugins/org.eclipse.equinox.launcher_1.3.201.v20161025-1711.jar org.eclipse.equinox.launcher.Main -registryMultiLanguage -debug -application net.bluemind.application.launcher.coreLauncher

C’est cet agent, attaché à nos machines virtuelles, qui nous permet d’exposer nos métriques applicatives à Telegraf. Que fait-il ?
Il ouvre un socket unix dans /var/run/bm-metrics, pour chaque JVM :

Ces sockets unix sont interrogés par Telegraf pour obtenir les métriques de chaque composant :

curl –unix-socket /var/run/bm-metrics/metrics-bm-lmtpd.sock http://bm/metrics

Qui nous donne en version simplifiée :

Ces données vont être consommées par Telegraf toutes les 10 secondes et…

Dashboards !

Ceci est un exemple de tableau de bord sur le flux de mail pre-configuré dans BlueMind 3.5.9.
Mais de nombreuses autres métriques sont disponibles : système (disques, charge, trafic réseau), postgresql (QPS, shared buffers usage), nginx.

Les données sont historisées sur une fenêtre de 7 jours, donc plus de mystère sur le disque dur qui était encore plein 2 heures avant de remonter un incident.

Alerting

Connaître le nombre de processus IMAP actifs, c’est bien. Le comparer avec le maximum configuré c’est mieux.

Cette métrique est observée en permanence par Kapacitor (le script imap-connections est configuré par bluemind) pour comparer le nombre de process à un instant avec celui configuré dans BlueMind.

Ces alertes sont visibles sur l’accueil du monitoring/tick/ de votre BlueMind avec le mot de passe de l’assistant d’installation.

Annotations

En corrolaire des alertes viennent les annotations, qui nous permettent de pointer des points dans le temps (ou des plages de temps) sur nos graphes.
Si le Core est redémarré par un administrateur, la supervision l’archive et le montre sur tous les graphes :

Les tâches programmées qui s’exécutent dans votre système sont aussi intégrées sur les graphes dès qu’elles prennent plus de 30 secondes. Plus de doute désormais pour diagnostiquer que les lenteurs ressenties par les utilisateurs sont dues à une sauvegarde ou un import d’annuaire.

La suite

De nombreuses métriques sont enregistrées par notre produit mais toutes ne sont pas encore exploitées dans des graphes ou des scripts d’alerting. Les dashboards et scripts d’alerting peuvent être ajoutés à BlueMind via des plugins et les prochaines versions devraient en amener de nouveaux et proposer des fonctions de « self healing » (quand tel problème survient, la solution est connue et donc appliquée de manière automatique).

Découvrez toute la documentation ici

Suivez nous :