Contexte et problème

Le développement assisté par IA a multiplié le nombre de tests unitaires et d’intégration chez Linear, faisant passer la taille du suite de tests à presque quatre fois son niveau d’origine. Chaque pull request (PR) doit encore traverser le pipeline d’intégration continue (CI), ce qui a transformé le CI en goulot d’étranglement. Le temps moyen d’attente d’une PR est passé de plus de six minutes à environ cinq minutes, tandis que le temps d’exécution d’un test a été réduit d’environ 50 %.

Optimisations d’infrastructure et d’outils

Linear a déplacé ses workloads de GitHub Actions vers des runners tiers équipés de CPU plus rapides, de stockage à haute performance et d’un cache plus efficace. Une comparaison avant‑après montre une accélération moyenne de 34 % des jobs, avec le compilateur tsc qui a gagné 52 % de vitesse. Le passage à tsgo, le compilateur natif TypeScript, a réduit le temps médian du contrôle de type de 73 %, éliminant ainsi le goulet d’étranglement du typage.

Le linting, auparavant dépendant du graphe de types, a été refondu pour s’appuyer uniquement sur l’analyse syntaxique de l’AST. Cette refonte a permis à ESLint de supprimer complètement TypeScript, entraînant une baisse de 68 % du temps de linting API et de 55 % du linting du dépôt complet, ainsi qu’une réduction notable de la consommation mémoire. L’adoption ultérieure d’Oxlint a encore diminué les minutes de runner consacrées au linting.

Optimisations des jobs CI

Les jobs de détection de changements, qui décident des étapes suivantes, ont été optimisés en limitant la profondeur de fetch (de 94 s à 20 s) et en supprimant totalement le checkout lorsqu’il n’était pas requis (de 27 s à 7 s). Un checkout « sparse, blobless » avec historique limité a économisé environ 11 s supplémentaires. Ces ajustements ont fait passer la durée médiane du job de détection de 26 s à 8 s, le p90 de 31 s à 12 s et le plus long de 138 s à 37 s.

Face à des temps de checkout instables dus à la liaison IP des runners tiers, l’équipe a remplacé actions/checkout par une action composite personnalisée qui réessaye avec back‑off et impose GIT_HTTP_LOW_SPEED_LIMIT et GIT_HTTP_LOW_SPEED_TIME. Cette stratégie a réduit les blocages critiques où un job attendait indéfiniment le checkout.

Enfin, la suppression de l’écriture de marqueurs de cache du chemin critique, déplacée après la fin des shards de tests, a économisé 42 s par PR API, et la pré‑installation de dépendances partagées (client Postgres) dans une image CI de base a éliminé 7‑8 s d’installation par shard.

Résultats et limites

Les mesures combinées ont permis de réduire d’environ une minute le temps de vérification requis pour les PR API en cas de cache manquant, tout en diminuant le nombre de démarrages de runners. Cependant, la croissance continue du nombre de tests, alimentée par l’IA, impose une pression permanente sur le système. Sans nouvelles optimisations ou une refonte architecturale (ex. exécution parallèle à plus grande échelle), le CI risque de redevenir un facteur limitant. De plus, la dépendance à des runners externes expose le pipeline à des instabilités réseau, malgré les mécanismes de résilience mis en place.