Plus tôt cette année, Tuomas, notre CTO, m'a assigné un problème : « Les coûts de CI sont élevés. » Il voulait aussi que la CI soit plus rapide. Les agents accélèrent la livraison, mais la validation des changements n'a pas suivi le rythme. Chaque PR doit passer par la CI, donc à mesure que le développement s'accélère, la CI devient un goulot d'étranglement, augmentant les coûts d'infrastructure et laissant les développeurs attendre plus longtemps pour obtenir des retours. Chez Linear, nous avons optimisé pour le temps d'attente des PR et le temps d'exécution. Malgré des suites de tests presque quadruplées, nous avons réduit le temps d'attente des PR de plus de 6 minutes à un peu plus de 5, et divisé par deux le temps d'exécution par test.

Nous avons amélioré la CI de quatre façons : mise à niveau de l'infrastructure et des outils, optimisation des tâches qui contrôlent d'autres travaux, réduction de la configuration répétée et exécution des tests plus efficace. La base de code de Linear est principalement en TypeScript, mais de nombreuses optimisations s'appliquent à tous les langages.

Le déplacement des charges de travail de GitHub Actions vers des runners tiers avec des CPU et un stockage plus rapides a réduit les temps de tâche de 34 % en moyenne, avec tsc en baisse de 52 %. Le passage à tsgo a réduit la médiane hebdomadaire de la vérification tsc de 73 %. La réécriture des règles de lint pour utiliser l'analyse statique a permis à ESLint d'abandonner TypeScript, réduisant le temps de lint de l'API de 68 % et le lint de tout le dépôt de 55 %. Le passage à Oxlint a encore réduit les minutes de runner. Nous avons également optimisé les tâches de contrôle, en limitant la profondeur de fetch pour réduire le contrôle le plus lent de 94 secondes à 20.