Une condition de qualité est une vérification que le travail doit passer avant de pouvoir avancer. Les portefeuilles permettent de transformer le critère « suffisamment bon pour être livré » d'une appréciation subjective en une règle que le système applique systématiquement.
Bloquant et consultatif
Chaque portefeuille est l'un ou l'autre, et cette distinction constitue l'essence même de la conception :
- Bloquant — en cas d'échec, la tâche est interrompue. Le travail ne peut pas progresser tant qu'il ne passe pas la vérification ou qu'un humain n'intervient pas pour l'autoriser.
- Consultatif — l'échec est enregistré comme une observation et joint à la demande de fusion, mais la tâche continue son cours.
Commencez par des règles consultatives. Observez pendant une ou deux semaines ce qu'un portefeuille signale réellement sur des tâches concrètes, puis promouvez ceux qui le méritent au statut bloquant. Un portefeuille trop strict dès le premier jour, sans avoir été calibré au préalable, incite surtout les équipes à contourner ses règles.
Portail bloquant
- Couverture inférieure à 80 %Échec
La tâche s'arrête
Elle revient sous forme de retravail plutôt que d'ouvrir une pull request que vous rejetteriez forcément.
- Une personne habilitée peut l'annuler. L'annulation indique qui, quand et pourquoi.
Portail consultatif
- Couverture inférieure à 80 %Échec
Un résultat est enregistré
La tâche poursuit son chemin jusqu'à l'examen.
- Le résultat est joint à l'pull request afin que vous puissiez l'évaluer.
Ce que les portefeuilles peuvent vérifier
Les portefeuilles 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 lintering et l'analyse statique
- l'analyse de sécurité, configurée dans Sécurité
- des tests navigateur sur une prévisualisation en cours d'exécution
- les preuves fournies par des prestataires externes et jointes à l'pull request
Le portefeuille le 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ù un portefeuille peut-il bloquer le travail ?
Les portefeuilles s'exécutent lors de la vérification, après l'achèvement par l'agent développeur et avant la Révision. Un échec bloquant renvoie la tâche en tant que retravail plutôt que de produire une pull request que vous finiriez par rejeter.
Cet ordre est délibéré : il est moins coûteux de constater un échec durant l'exécution que sur votre écran.
Stratégies
Les portefeuilles sont regroupés dans des stratégies, qui sont celles que vous attachez réellement aux projets. Une stratégie est un ensemble nommé de portefeuilles avec leurs paramètres bloquants ou consultatifs, ce qui vous permet d'avoir une stratégie standard pour les services de production et une version plus souple pour les outils internes.
Les stratégies sont versionnées. Vous publiez une modification, et vous pouvez revenir à une version antérieure si un nouveau portefeuille s'avère trop restrictif.
Exceptions
Un portefeuille bloquant peut être contourné par une personne ayant l'autorité nécessaire. Cette exception est enregistrée — qui, quand et sur quelle tâche.
Cet enregistrement est essentiel. Un portefeuille qu'on ne peut pas contourner devient quelque chose que les équipes cherchent à éviter ; un portefeuille que tout le monde peut contourner sans laisser de trace n'est pas un véritable portefeuille. Une exception qui laisse une trace est à la fois utilisable et traçable.
Ce que les portefeuilles ne font pas
Les portefeuilles vérifient des propriétés. Ils 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 de votre processus de Révision.
Une modification peut passer tous les portefeuilles et rester néanmoins inappropriée.