Pourquoi nous avons créé un framework de test open source

Créer des logiciels et participer à une communauté open source était et continue d'être une expérience amusante, éducative et enrichissante.

Si vous avez toujours voulu rejoindre une communauté open source et contribuer ou démarrer votre propre projet open source, lisez la suite pour découvrir notre projet open source amusant et génial que nous avons créé de toutes pièces chez Red Hat. Je suis responsable de l'ingénierie de la qualité logicielle au sein du groupe OpenStack Networking, et avec une équipe d'ingénieurs de mon équipe et de la R&D, nous avons collaboré pour créer le cadre de test open source Tobiko.

Parfois, il suffit de démarrer un nouveau projet open source.

Notre point de départ était bon. Nous disposions déjà d'un cadre de test open source officiel appelé Tempest qui s'efforçait de couvrir complètement l'API OpenStack et les scénarios courants simulant un cloud fonctionnel.

Les équipes OpenStack avec lesquelles je travaille créent fréquemment de nouveaux tests et les exécutent sur diverses configurations cloud, à l'aide de systèmes open source d'intégration continue : Jenkins pour l'aval et Zuul pour l'amont.

Mais le cloud OpenStack est adopté massivement par les secteurs des télécommunications et des entreprises. Nous connaissions une croissance rapide de la complexité, ce qui impliquait davantage de scénarios de tests, et nous découvrions que nos anciens outils n'étaient tout simplement plus adaptés.

Définir l'enjeu, définir les besoins

Nous avons rapidement compris que la première étape fondamentale consistait à définir les nouveaux besoins de nos clients. Cela nous a obligé à rechercher les problèmes signalés par les clients. Nous avons examiné la base de données des bugs sur le terrain, divisé tous les problèmes en plusieurs sections et analysé les données.

L'étape suivante consistait à examiner les projets existants. Il va de soi que l’adoption d’un projet existant devrait aller plus vite que l’invention d’un nouveau projet à partir de zéro. Et pourtant, nous n’avions pas trouvé d’outil adapté à nos besoins, ni d’outils open source que nous pourrions facilement adapter.

Comment cela s'est passé

C'est à ce moment-là que nous nous en sommes rendu compte.

Il était temps d’avancer dans la conception et la conception d’un nouveau projet.

Nous ne voulions pas entreprendre cette démarche sans réflexion sérieuse et sans apports diversifiés. Nous avons donc choisi d'utiliser le Open Decision Framework (ODF). Le principal avantage de cette méthodologie est d'obtenir autant de retours que possible dès les premières étapes de développement du projet, ce qui nous a permis de gagner beaucoup de temps. plus tard.

Après quelques réunions, au cours desquelles nous avons eu des séances de brainstorming productives, nous avons d'abord rédigé quelques retours positifs et négatifs auxquels nous souhaitions sérieusement réfléchir.

Nous avons répété. Nous avons pris nos discussions et nos commentaires au sérieux et nous avons travaillé dur pour parvenir à une solution.

Finalement, nous nous sentions prêts à passer à la phase de mise en œuvre.

Nous avons commencé par rassembler un groupe de personnes qui avaient le temps, les capacités et peut-être plus important encore, la passion de conduire le projet conformément aux décisions que nous avions prises lors de la planification. Une fois que le projet a commencé à prendre forme, de plus en plus de contributeurs ont contacté l'équipe pour l'envisager pour leur nouveau framework.

Cela semble si rapide quand c'est écrit en seulement quelques paragraphes, mais ce processus était délibéré et nous l'avons traité avec beaucoup de respect. Depuis environ un an, nous disposons d'un noyau solide d'ingénieurs très compétents qui ont collaboré sur divers défis de développement pour prendre en charge l'infrastructure en évolution rapide du cloud.

Vous trouverez ci-dessous leurs témoignages sur le travail qu'ils ont réalisé, recueillis sous différents angles de personnes impliquées dans le projet.

Slawomir Kaplonski, ingénieur logiciel principal chez Red Hat

Qu'est-ce qui vous pousse à contribuer à des projets open source ?

Je contribue aux projets que j'utilise. Si je vois qu'il y a un bug qui me dérange ou une fonctionnalité manquante que j'aimerais voir là-bas, j'essaie de rechercher pourquoi c'est comme ça, au moins signaler un bug ou une demande d'amélioration (RFE) pour le projet. Et dans le meilleur des cas, j'essaie aussi de proposer un patch.

Cela peut être la principale raison pour laquelle les gens contribuent à un projet, ou du moins pourquoi ils le démarrent. C'est parce que plus tard, lorsque vous êtes davantage impliqué dans un projet, vous vous souciez davantage de ce projet, vous connaissez d'autres personnes autour du projet et les choses sont différentes.

Quel est l'avantage du fait que Tobiko soit open source ?

Si (quand) il est utilisé par des personnes de différentes équipes, peut-être même des entreprises, elles peuvent contribuer directement au projet, en y apportant leurs idées et leurs cas d'utilisation. Et ils peuvent contribuer, et contribueront, au code pour corriger les bogues qu’ils rencontrent et ajouter les nouvelles fonctionnalités dont ils ont besoin.

Rendre un projet open source le rend accessible à un large public, ce qui peut aider un projet à se développer.

Federico Ressi, ingénieur qualité logiciel senior chez Red Hat

En tant que principal contributeur à cet effort depuis le début du projet, quelles ont été les principales leçons que vous avez apprises en travaillant sur Tobiko ?

Certaines des leçons que j'ai reçues de Tobiko, sans ordre particulier, sont :

Évitez de faire fonctionner les choses le plus tôt possible, car les futures refactorisations ont souvent un coût beaucoup plus élevé. Il est préférable de soumettre de petites modifications incrémentielles au fil du temps.
Commencez à travailler seulement une fois que vous avez des exigences très bien articulées.
Utilisez un système d'intégration continue pour vous aider à tester votre propre code. Cela conduit à la stabilité.

Quel est l'avantage du fait que Tobiko soit open source ?

Le plus grand avantage du fait que Tobiko soit open source est de pouvoir réutiliser d'autres codes open source et l'infrastructure OpenDev. Cela augmente également la confiance des utilisateurs finaux et leur compréhension du projet.

Eduardo Olivares Toledo, ingénieur qualité logiciel senior chez Red Hat

Vous avez rejoint l'équipe alors que le projet était déjà en production. Comment s'est passé le fait de rejoindre le projet et la communauté existants ?

J'ai commencé à assister aux réunions Tobiko et à assumer de petites tâches de leur tableau Kanban. Les principaux contributeurs étaient les principaux points de contact techniques, et j'ai rapidement commencé à leur poser des questions techniques lorsque j'ai commencé à contribuer au projet.

J'ai également rejoint le canal IRC Tobiko et la liste de diffusion pour être informé et participer à différentes discussions.

Quelles ressources vous ont aidé à apprendre le projet ?

Une documentation en amont m'a principalement aidé à démarrer le téléchargement, l'installation et l'exécution des tests Tobiko.

J'ai également passé du temps à examiner les tâches CI existantes, et c'était un excellent moyen de comprendre comment Tobiko était utilisé avec Openstack, comment fonctionnent les tests Tobiko, et j'ai pu commencer à contribuer à la résolution de certains problèmes que j'ai trouvés.

Tobiko est basé sur des bibliothèques Python standards, telles que testtools et paramiko, ce qui facilite le processus de montée en puissance (soit vous les connaissez si vous avez une certaine expérience des frameworks de test Python, soit de nombreuses documentations sont disponibles).

Quel est l'avantage d'être open source ?

Les projets open source présentent plusieurs avantages bien connus. Je soulignerais les suivants :

Contribution et commentaires de personnes de différentes organisations et entreprises. Le projet Tobiko n'a pas encore atteint cet objectif car tous les contributeurs sont des associés de Red Hat. Federico a présenté Tobiko lors du dernier OpenStack PTG à la communauté Neutron, et j'espère que d'autres personnes s'impliqueront dans le projet.
Boucles de rétroaction plus courtes en raison des tâches CI exécutées en amont. Ceci est déjà en place car les tâches Tobiko CI sont exécutées avec chaque nouveau correctif Tobiko sur la dernière version d'OpenStack. Pour cette raison, certains bugs d’OpenStack ont été découverts très tôt. Tobiko s'exécute dans une file d'attente de tâches périodique pour Neutron, ce qui signifie qu'il vérifie quotidiennement les portes de la branche principale, une réalisation remarquable pour Tobiko.

Créez des logiciels ensemble

De mon point de vue en tant que manager de l'organisation et membre de l'équipe et du projet, j'ai identifié plusieurs points critiques qui ont aidé le projet à croître plus rapidement et à réaliser la valeur que nous recherchions :

Expérience : Au début du projet, j'ai reconnu le besoin d'un membre expérimenté de la communauté open source pour rejoindre l'équipe pour aider sur des sujets liés à la communauté.
Division du travail : Nous avons décidé de promouvoir davantage de personnes au rôle de révisions principales afin d'accélérer le cycle de développement et de répartir les responsabilités entre les membres de l'équipe.
Éducation : Nous devions attirer davantage d'attention sur le projet pour inciter davantage de personnes à se joindre à l'effort. Nous avons organisé des conférences lors de réunions pertinentes à l'intérieur et à l'extérieur de l'entreprise, envoyé des e-mails avec des exemples de nouvelles fonctionnalités et réalisations et, de manière générale, contribué à promouvoir le projet.

Créer des logiciels et participer à une communauté open source était et continue d'être une expérience amusante, éducative et enrichissante. Cela m'a appris plus que jamais la valeur de l'open source et je suis heureux d'avoir eu la chance de travailler dessus avec un groupe de personnes très talentueuses et motivées.

Merci Federico Ressi, Slawek Kaplonski, Pini Komarov, Eduardo Olivares Toledo, Alex Katz, Omer Scwartz, Assaf Muller et Arie Bergman.

Si vous êtes intéressé par les tests OpenStack, rejoignez notre projet !