Summary
Cette présentation s'adresse à tout développeur soucieux de la qualité du code, intéressé par les problématiques d'intégration et de développement continus, et travaillant sur un projet comptant plus de 2 contributeurs. Elle se concentre sur Zuul, un système de "gating" des contributions à un ensemble de projets.
Description
Les projets de grande échelle comme OpenStack, intégrant plus d'une centaine de contributions par jour en moyenne, ne pourraient aboutir sans un contrôle rigoureux de la qualité du code. C'est pourquoi l'une des tâches majeures des développeurs principaux ("core devs") d'OpenStack est de passer en revue les contributions ("code review") puis d'éventuellement les valider pour intégration au code source. Mais comment gérer un tel flux de contributions en un temps raisonnable ? Comment être certain qu'une contribution acceptée par un core dev ne va pas avoir des effets de bord sur une autre contribution acceptée simultanément par quelqu'un d'autre, ou sur un projet connexe ?
La communauté OpenStack utilise un outil codé en Python appelé Zuul (en référence à Ghostbusters) pour répondre à ces problématiques, et permettre aux core devs de ne pas avoir à consacrer 100% de leur activité à la revue de code. L'intérêt de Zuul est clair pour tout projet, quel que soit son envergure, nécessitant un contrôle rigoureux pour l'intégration et le déploiement continus. Nous présentons donc ici les principales fonctionnalités de Zuul à travers des cas d'usage simples, et telles que nous les utilisons dans le projet Software Factory, une suite logicielle libre "all in one" de gestion de code, poussé par Red Hat.
Nous couvrirons les sujets suivants:
- Comment Zuul interagit avec Gerrit, le service de revue du code
- Que signifie la notion de "pipelines" dans Zuul, et comment les utiliser
- Quelle stratégie suit Zuul pour gérer la queue des contributions à tester ou à intégrer
- Comment Zuul gère les interdépendances de projets
- Exemples de workflows de CI et CD facilités par Zuul