Une porte de qualité est une vérification que le travail doit passer avant de pouvoir avancer. Les portes permettent de transformer le critère « suffisamment bon pour être livré » d'une appréciation subjective en une règle appliquée systématiquement par le système.
Blocantes et consultatives
Chaque porte est l'une ou l'autre, et cette distinction constitue l'essence de la conception :
- Blocantes — en cas d'échec, la tâche est arrêtée. Le travail ne progresse pas tant qu'il ne passe pas ou qu'un humain n'intervient pas pour l'autoriser.
- Consultatives — en cas d'échec, celui-ci est enregistré comme constat et joint à la demande de fusion, mais la tâche continue tout de même.
Commencez par des portes consultatives. Observez ce qu'une porte signale réellement sur des travaux concrets pendant une ou deux semaines, puis promouvez celles qui le méritent au statut blocante. Une porte qui bloque dès son premier jour, sans avoir été calibrée au préalable, incite surtout les équipes à contourner ses règles.
Ce que les portes peuvent vérifier
Les portes s'appliquent à l'étape de vérification et peuvent couvrir :
- le bon fonctionnement de votre propre suite de tests
- les seuils de couverture de code
- le linting et l'analyse statique
- l'analyse de sécurité
- les tests dans le navigateur sur une prévisualisation en cours d'exécution
- les preuves fournies par des prestataires externes et jointes à l'pull request
La porte la plus utile est presque toujours votre suite de tests existante, car elle reflète déjà ce que votre équipe considère comme essentiel.
Où une porte peut interrompre le travail
Les portes s'exécutent lors de la vérification, après que l'agent développeur a terminé son travail et avant la Révision. Un échec blocant renvoie la tâche en tant que correction plutôt que de produire une pull request que vous finiriez par rejeter.
Cet ordre est volontaire : il est moins coûteux de rencontrer un échec durant l'exécution que sur votre écran.
Politiques
Les portes sont regroupées dans des politiques, qui sont ce que vous attachez réellement aux projets. Une politique est un ensemble nommé de portes avec leurs paramètres blocants/consultatifs, ce qui vous permet d'avoir une politique standard pour les services de production et une politique plus souple pour les outils internes.
Les politiques sont versionnées. Vous publiez une modification, et vous pouvez revenir à une version antérieure si une nouvelle porte s'avère trop restrictive.
Exceptions
Une porte blocante peut être contournée par une personne ayant l'autorité nécessaire. Cette exception est enregistrée — qui, quand et sur quoi.
Cet enregistrement est essentiel. Une porte qu'on ne peut pas contourner devient quelque chose que les équipes cherchent à éviter ; une porte que n'importe qui peut contourner sans laisser de trace n'est pas une véritable porte. Une exception qui laisse une trace est à la fois utilisable et traçable.
Ce que les portes ne font pas
Les portes vérifient des propriétés. Elles ne jugent pas si le travail résout le bon problème — c'est l'objectif des critères d'acceptation dans la spécification et ce pour quoi sert votre Révision.
Un changement peut passer toutes les portes et rester néanmoins un mauvais changement.