La CI est l’endroit où une équipe de développement découvre si un changement tient la route. C’est aussi là que le temps disparaît. Une demande de tirage (pull request) attend un exécuteur. Une suite de tests attend de la capacité. Une version attend que la file se vide. Ces délais sont faciles à accepter un à un, mais ils s’additionnent sur une semaine de petits changements et pour une équipe qui essaie de faire avancer le travail.

Je voyais sans cesse le même compromis. Les exécuteurs hébergés suppriment le travail d’infrastructure, mais les équipes ont peu de contrôle sur le temps de démarrage et la performance. Les exécuteurs autohébergés offrent plus de contrôle, mais les équipes doivent entretenir des parcs, des images, des frontières d’accès et le nettoyage. Les équipes ne devraient pas avoir à choisir entre une rétroaction rapide et un modèle d’exploitation gérable.

Le calcul de CI devrait s’effacer.

C’est pourquoi j’ai fondé Runzivo. Le calcul de CI devrait être prêt quand une tâche en a besoin, isolé pendant son exécution et disparu à la fin. Le flux de travail devrait rester familier. Runzivo devrait s’occuper de l’infrastructure qui le soutient.

Ce problème est volontairement étroit. Je n’introduis pas un nouveau langage de CI et je ne demande pas aux équipes de reconstruire des pipelines qui fonctionnent. Je commence là où un flux de travail demande une machine. Un petit changement est plus facile à évaluer, à annuler et à intégrer aux systèmes que les équipes utilisent déjà.

Ce que je construis en premier.

La V1 est du calcul Linux x64 géré pour GitHub Actions. Chaque tâche approuvée reçoit un environnement isolé et éphémère. Quand la tâche se termine, cet environnement est détruit. Les équipes installent l’application GitHub Runzivo, choisissent les dépôts qu’elles veulent utiliser et modifient l’étiquette runs-on dans un flux de travail. Leurs étapes existantes restent en place.

La première version est délibérément précise. Elle ne promet pas tous les systèmes d’exploitation, toutes les architectures ni tous les fournisseurs de CI. Elle se concentre sur une seule intégration et une seule cible d’exécuteur. Cela me donne un modèle d’exploitation clair à mettre à l’épreuve avec de vraies tâches. Je mesurerai la performance avant d’avancer des affirmations sur la vitesse. Pour la V1, l’objectif est simple : moins d’attente autour d’un flux de travail de CI.

Les principes derrière le service.

Runzivo repose sur quelques principes. Une tâche obtient un environnement isolé. Le calcul est éphémère et n’est pas réutilisé d’un client à l’autre. L’intégration GitHub reste simple. Les clients ne devraient pas avoir un parc d’exécuteurs à corriger, à dimensionner ou à nettoyer. Ce sont des engagements de conception de la V1. Les premiers utilisateurs m’aideront à les mettre à l’épreuve en pratique.

Un cycle de vie clair de l’environnement m’aide à raisonner sur la sécurité et la performance. Il est plus facile à inspecter qu’un environnement partagé entre plusieurs tâches. Une petite surface de produit rend aussi les limites plus faciles à comprendre. Je garde la V1 étroite pour que les utilisateurs sachent ce qu’elle fait, où se situent ses limites et comment signaler les lacunes.

Pourquoi maintenant.

Les équipes livrent plus de changements et automatisent une plus grande part du travail qui les entoure. Le code généré, les suites de tests plus volumineuses et les vérifications supplémentaires sur les demandes de tirage mettent toutes la CI sous pression. Le goulot d’étranglement n’est souvent pas la personne qui écrit le changement. C’est l’attente entre l’envoi pour validation et la réception d’une réponse utile.

Je ne pense pas que chaque équipe ait besoin d’une nouvelle plateforme de livraison pour répondre à cette pression. Beaucoup d’équipes ont déjà des flux de travail en lesquels elles ont confiance. Il leur faut un meilleur endroit où exécuter certaines tâches. C’est l’ouverture concrète pour Runzivo : garder le flux de travail familier et rendre la couche de calcul plus facile à utiliser et à exploiter.

Ce qui vient après la V1.

GitLab, macOS, des régions supplémentaires et l’observabilité sont des orientations de la feuille de route, pas des fonctionnalités de la V1. Je les envisagerai après que les premiers utilisateurs auront testé l’expérience GitHub Actions et Linux x64. Un élément de la feuille de route n’est pas une fonctionnalité disponible.

Mon travail immédiat est plus modeste. Construire soigneusement le premier service. Écouter les équipes qui l’essaient. Publier des limites claires. Améliorer ce qui tient le coup à l’usage. Laisser le reste sur la feuille de route jusqu’à ce que cela mérite sa place dans le produit.

Construisez avec moi.

Je travaille dès maintenant avec les premiers utilisateurs. Si votre équipe passe trop de temps à attendre GitHub Actions, j’aimerais connaître les flux de travail qui causent le plus de friction. Demandez l’accès anticipé et dites-moi ce que vous essayez d’exécuter.

Runzivo en est à ses débuts, reste ciblé et est ouvert aux commentaires de ceux qui l’utilisent. Commencez par un flux de travail. Aidez-moi ensuite à réduire l’attente.