L’article d’aujourd’hui est sérieux.
Je préfère le dire parce que, comme vous le savez, ce n’est pas toujours le cas avec moi. Si cet article est sérieux, c’est parce que je vais vous expliquer comment nous améliorons au quotidien l’Incroyable Plateforme de Services de Contenu Nuxeo[1].
Et tout ça passe par la présentation détaillée de nos processus d’assurance qualité (Quality Assurance - QA) et d’intégration continue (Continuous Integration - CI). Et chez Nuxeo, c’est quelque chose que nous prenons au sérieux.
Et pour que ça soit toujours le cas, Nuxeo s’est assuré que je sois le moins impliqué possible. C’est l’équipe de développement (Engineering) qui s’en charge : développeurs (back-end et front-end), équipe QA, DevOps, SysAdmin, etc.
En fait, tout le monde chez Nuxeo, sauf moi… Et c’est pour ça que ce processus est aussi efficace.
Chez Nuxeo, notre philosophie de transparence et d’ouverture ne se limite pas au code que nous écrivons. Tout est open source, même nos processus internes.
Au quotidien, nous sommes complètement transparents sur le développement et l’amélioration de Nuxeo, cette solution incroyablement puissante et géniale que vous utilisez déjà, ou que vous allez bientôt utiliser[2]. La documentation QA/CI explique tout, et si vous la lisez, vous verrez que nous faisons appel aux dernières technologies (par ordre d’apparition) : GitHub, Jenkins, Maven et de nombreux outils de test (unitaire et fonctionnel) qui sont listés ici.
La vision globale
Ces processus sont résumés dans le schéma suivant[3] :
Ce schéma illustre mon propos et les principes fondamentaux qui se cachent derrière le développement continu de Nuxeo Platform. Sur certains aspects de la plateforme, d’autres éléments et processus peuvent être impliqués.
Par exemple, la modification d’un add-on optionnel (Nuxeo Vision, Digital Signature, etc.) n’aura pas le même impact que la modification de l’un des plug-ins fondamentaux (comme ceux qui gèrent le stockage des bases de données back-end). Et ce processus n’est pas toujours aussi séquentiel que dans le schéma. Des révisions du code, des sessions brainstorming et de légers “ajustements” peuvent intervenir à toutes les étapes.
L’explication de cette vision globale
Voici les principaux processus de QA/CI utilisés chez Nuxeo :
Un développeur Nuxeo termine un plug-in (appelons-le Plug-in A) ajoutant de nouvelles fonctionnalités ou corrigeant des bugs sur une branche dédiée (personne ne doit travailler directement dans la branche principale, dite master). La plateforme s’appuie sur une architecture de type Component Model, donc tous les éléments sont considérés comme des plug-ins et il n’est pas nécessaire de modifier le code source : les développeurs de la plateforme travaillent sur un plug-in à la fois (Nuxeo WebUI, Nuxeo S3 Storage, Nuxeo LiveConnect, Bulk Document Importer, etc.).
Le développeur teste son travail en local, et s’il est satisfait, il peut publier ses modifications sur GitHub. S’il n’est pas satisfait, retour à la case départ…
Une fois sur GitHub, un “hook” permet à notre serveur Jenkins de détecter que le Plug-in A a été modifié. Jenkins récupère les modifications et…
4…. Demande à Apache Maven d’intégrer le Plug-in A dans la branche du développeur. C’est la phase de build et de test. Et c’est lors de cette phase que d’autres éléments et sous-processus peuvent intervenir : sur certains plug-ins, un élément déclencheur (“trigger”) initiant la compilation de tous les modules dépendants ou des tests fonctionnels ou de performances sur une version de la plateforme comprenant le plug-in.
La compilation et les tests se sont bien passés sur nos serveurs Jenkins. Le fait de préciser “sur nos serveurs” est très (mais vraiment très très) utile pour échapper aux phrases du type « Mais ça marche sur mon ordinateur »… Le développeur peut effectuer une pull request pour que les modifications soient fusionnées (“merged”) dans la branche master. Au moins deux autres développeurs vont jeter un œil au code et valider les changements. En d’autres termes, les étapes 1 à 4 vont se répéter jusqu’à ce que tout le monde valide le travail effectué.
C’est à ce moment-là que la branche du développeur est intégrée à la branche master, et les choses sérieuses commencent vraiment.
Maven compile le plug-in dans la branche et le teste.
Si tout va bien, le plug-in est compilé dans un package…
…et les multiples procédures de validation peuvent commencer : tests fonctionnels, tests de performances, tests matriciels… etc.
Si “tout” va bien, le plug-in est publié sur la Nuxeo Marketplace et nos clients peuvent le télécharger. Ils peuvent aussi faire appel à leurs propres outils d’intégration/déploiement pour le récupérer automatiquement. L’automatisation est très simple (il suffit d’ajouter
./nuxeoctl mp-install the-plugin-artifact-id, et voilà.)
Par ailleurs, après l’étape 9, nos différents serveurs de tests manuels sont mis à jour dans le cadre d’un processus de déploiement continu grâce à des scripts Ansible, des conteneurs et toutes les dernières technologies tendance (enfin, il faut être un peu geek pour trouver ça tendance).
Et vous avez certainement remarqué Sonar dans le schéma. Nous faisons appel à Sonar pour vérifier la qualité et la couverture de notre code. Une fois la branche master compilée, Sonar reçoit les modifications sur GitHub et nous donne plus d’informations sur le code (sa couverture et les problèmes potentiels que les développeurs et les validateurs pourraient avoir manqué).
Le processus en détail
Vous savez quoi ? Tout est automatisé !
Enfin. Bien sûr que c’est automatisé… Qui voudrait payer des gens pour cliquer sur un bouton “Télécharger depuis GitHub”, “Compiler”, “Prévenir Sonar” ou “Lancer les tests” ?
Pour être honnête, toutes les étapes ne sont pas automatisées à 100 %. Par exemple, la première étape fait appel au cerveau de nos brillants développeurs pour qu’ils imaginent et écrivent le meilleur code possible.
Et en cas de soucis, les bonnes personnes sont prévenues. Le développeur reçoit (naturellement) une alerte, mais les autres développeurs et les managers aussi pour que le plug-in puisse être corrigé au plus vite (même si Nuxeo est une entreprise super cool, nous avons quand même des comptes à rendre).
Pour exécuter ces processus, nous lançons (automatiquement ou à la demande) des conteneurs Jenkins dans Docker au sein de notre infrastructure Cloud sur AWS.
Vous pouvez suivre tout ça sur qa.nuxeo.com, notre site de QA ouvert au public (Je vous ai déjà dit qu’on était super ouverts ?). N’hésitez pas à nous contacter quand vous le voulez pour en parler : tous les mois, toutes les semaines, tous les jours, toutes les heures… Vraiment quand vous voulez. Vous aurez toujours la réponse aux questions de type Quoi / Pourquoi / Qui / Comment que vous vous posez sur nos processus de QA/CI. Qu’est-ce nous avons développé, pourquoi nous l’avons développé (souvent un ticket JIRA), comment le code a-t-il été modifié et qui l’a modifié. Et si les tests ont échoué, vous pouvez toujours en vouloir au développeur (mais bon, ce n’est pas conseillé, sauf si vous lui envoyez aussi des cadeaux un peu geek).
Le futur
Au début de cet article, je vous ai annoncé que des éléments et sous-processus supplémentaires pouvaient être impliqués en fonction du plug-in. Le Test & Push est l’un de ces processus. Il entre en jeu lorsqu’un développeur modifie un élément susceptible d’impacter l’ensemble de la plateforme.
Par exemple, un développeur veut mettre à jour la bibliothèque JSON utilisée par Nuxeo. L’impact sur le reste de la plateforme peut être considérable et tester un seul plug-in ne suffit pas. Le développeur doit exécuter un test Test & Push, qui lance la compilation et le test de l’ensemble de la plateforme. Même si ce processus peut être déclenché automatiquement, il nécessite beaucoup de temps et une puissance de calcul considérable et nous préférons l’exécuter lorsque c’est nécessaire (comme aujourd’hui).
Nos équipes se demandent toujours comment ajuster et améliorer nos processus. Dans le cas présent, nous aimerions pouvoir diviser les différentes tâches. Tester l’ensemble de la plateforme Nuxeo prend du temps parce que les tests sont exécutés les uns après les autres, même si la plupart d’entre eux ne sont pas liés. Par exemple, les tests nuxeo-platform-renditions et nuxeo-platform-tag devraient pouvoir être simultanés. Nous voulons donc nous appuyer sur Jenkins et Docker pour diviser cet énorme processus Test & Push en plusieurs tests et vérifications pouvant être exécutés en parallèle. Cela nous permettra d’utiliser plus efficacement nos ressources CI tout en bénéficiant de résultats plus rapides.
Conclusion
Nuxeo ne plaisante pas avec ses processus de QA/CI.
(Difficile de faire plus court !)
[1] Cet acronyme n’est pas validé par l’équipe Marketing, je l’ai juste inventé pour cet article.
[2] Vous rassemblez peut-être des informations sur Nuxeo et vous êtes tombé sur cet article. Si je dis ça, c’est que je ne vois vraiment pas de raison valable de passer à côté de la meilleure plateforme de services de contenu au monde.
[3] Ma première idée était un peu différente.
J’avais pensé à ce schéma :
Mais quand je l’ai montré à Thierry Delprat (CTO chez Nuxeo), j’ai bien vu dans son regard qu’il avait envie de me balancer un truc, donc j’ai opté pour une version plus complète. Enfin bon, les CTO…