À quoi ressemble un bon pipeline CI pour un service backend ?

Il tourne à chaque push, rend son verdict en moins de dix minutes, et bloque la fusion en cas d'échec. Ordonnez les étapes du moins cher au plus cher : lint et vérifications de types, tests unitaires, puis tests d'intégration contre de vraies dépendances en conteneurs, puis un seul artefact de build que vous promouvez au lieu de le reconstruire par environnement. Gardez-le déterministe, mettez les tests instables en quarantaine au lieu de relancer à l'aveugle, et rendez les mêmes vérifications exécutables en local.

La première propriété, c'est la vitesse, parce qu'un pipeline qui prend quarante minutes est un pipeline que les gens contournent. Je veux que le lint et les vérifications de types échouent en moins d'une minute, les tests unitaires en quelques-unes, et l'ensemble sous dix minutes. Les étapes vont donc du moins cher au plus cher : vérifications statiques, tests unitaires, puis tests d'intégration contre de vrais Postgres et Redis en conteneurs plutôt que des mocks, parce que les bugs qui m'intéressent vivent à la frontière. Ensuite il construit un seul artefact, une image de conteneur étiquetée avec le sha du commit, et tous les environnements suivants déploient exactement cette image. Reconstruire par environnement veut dire que ce que vous avez testé n'est pas ce que vous avez livré. Sur les tests instables je suis strict : une relance automatique est une façon de cacher une vraie course, donc un test instable est mis en quarantaine et quelqu'un est responsable de le corriger dans la semaine. Et je veux les mêmes commandes exécutables en local, en général derrière un makefile, parce que déboguer en poussant des commits pour voir ce que dit la CI est une façon lamentable de passer un après-midi.