Une politique est un ensemble nommé et versionné de portes de qualité. Les politiques sont ce que vous attachez aux projets ; les portes sont ce qui s'exécute réellement.
Pour comprendre les concepts — bloquant vs consultatif, et l'emplacement des portes dans le processus d'exécution — lisez Portes de qualité en premier. Cette page traite de leur gestion.
Gérez-les dans Contrôle qualité. Sa liste affiche la politique par défaut de l'organisation et toutes celles des projets. Sélectionnez-en une pour voir comment le nouveau travail est filtré, ce qu'elle vérifie à chaque modification, son niveau de contrôle qualité et l'endroit où les vérifications s'exécutent ; chaque élément dispose d'un interrupteur qui s'applique dès que vous le basculez. La confirmation permet d'annuler le changement, et les paramètres d'une ligne modifient le fonctionnement de cette vérification.
- Configuration par défaut de l'organisation3 projets suivent cette configuration.2 sur 5
- Boutique en ligneConfiguration personnalisée4 sur 5
- Site de documentationSuivi de la configuration par défaut2 sur 5
- Facturation APISuivi de la configuration par défaut2 sur 5
- Application mobileSuivi de la configuration par défaut2 sur 5
- Anti-slopRenvoie un changement en arrière lorsqu'il affaiblit les tests, masque des erreurs, livre des espaces réservés ou génère une dette technique.
- Tests unitairesDétecte et exécute les tests unitaires du dépôt à chaque modification.
- Tests navigateur2 sur 3Diffère de la configuration par défautExécute vos parcours de navigation sur le changement apporté.
- TraductionsDiffère de la configuration par défautVérifie que les chaînes modifiées sont bien traduites et que leurs espaces réservés ainsi que leurs formes pluriels correspondent.
- Vérifications du dépôtExécute vos propres commandes, comme le formatage, la vérification de la taille des fichiers, les migrations, les tests d'intégration et les analyses de sécurité.
- Contrôle qualité approfondiApprofondiLe contrôle qualité collecte des preuves et des captures d'écran en temps réel par rapport à la Spécification. Lorsqu'il est désactivé, le travail bénéficie d'un contrôle qualité standard.
Contrôle qualité : les politiques en vigueur et la dernière exécution de la porte de validation. Données illustratives.
Créer une politique
Une politique est un ensemble de vérifications accompagnées, pour chacune, de l'indication si l'échec doit bloquer ou simplement conseiller.
La plupart des organisations ont besoin de deux ou trois politiques, pas une par projet :
- une strict politique pour les services de production
- une standard politique pour tout ce qui est courant
- et occasionnellement une léger politique pour les outils internes et les prototypes
Au-delà de cela, personne ne se souviendra plus de quelle politique s'applique à quel projet.
La politique par défaut de l'organisation et la configuration propre au projet
Un projet suit la politique par défaut de l'organisation jusqu'à ce que vous modifiiez l'un de ses interrupteurs. Ce changement lui donne sa propre configuration, copiée de la politique par défaut, et les modifications ultérieures de celle-ci n'affecteront plus le projet. Une ligne peut copier une vérification depuis la politique par défaut, et le menu du projet peut réinitialiser l'ensemble du projet à la politique par défaut de l'organisation. La politique complète sous-jacente aux interrupteurs, avec les attentes, les dépendances entre vérifications, les budgets de correction et les versions, s'ouvre depuis le même menu que l'éditeur avancé. Pour un projet qui suit la politique par défaut, l'éditeur démarre à partir d'une copie de celle-ci, et rien ne change pour le projet tant que vous n'avez pas publié cette copie.
Configurez la politique par défaut sur votre standard vérifications, celles que la plupart des projets devraient exécuter, pas vos règles les plus strictes — ces dernières devant être activées volontairement, projet par projet.
Demandes de fusion
Les demandes de fusion ouvertes par les personnes et d'autres outils arrivent sur Coroid via l'application Coroid GitHub. Le groupe Demandes de fusion dans le Contrôle qualité décide de leur sort, pour la politique par défaut de l'organisation et pour chaque projet :
- Contrôle qualité Coroid exécute les vérifications ci-dessus sur chaque pull request et rapporte le résultat comme la vérification Contrôle qualité Coroid sur GitHub.
- Révision Coroid fait en sorte que le lecteur de Coroid examine chaque pull request et commente les lignes qu'il remet en question. Il lit les demandes de fusion que le Contrôle qualité Coroid a vérifiées.
Paramètres de la Révision Coroid :
- Ce qu'elle publie. Le mode consultatif, par défaut, commente sans jamais faire échouer la vérification. Le mode bloquant déclenche un échec de la vérification dès qu'un problème est détecté. Pour qu'une révision bloquante empêche la fusion, configurez la Révision Coroid comme vérification obligatoire dans GitHub.
- Quelles demandes de fusion. Par défaut, elle attend que le brouillon soit marqué comme prêt et ignore les demandes de fusion ouvertes par Coroid, car le lecteur de Coroid les a déjà examinées dans le cadre de la tâche. Elle peut également ignorer les demandes de fusion provenant de robots.
- Quand elle effectue la révision. Elle attend une période de calme après le dernier transfert de code, cinq minutes par défaut. Un nouveau transfert annule une révision qui n'a pas encore commencé. La commande Re-exécuter sur GitHub lance immédiatement une nouvelle révision.
- Profondeur de la révision. Ce que le lecteur peut lire et écrire lors d'une seule révision.
Elle suit les règles de révision de Coroid et celles définies dans le dossier
review-rules de votre dépôt. Un projet qui suit la politique par défaut de l'organisation hérite des paramètres de celle-ci, comme pour tout autre contrôle.
Lorsqu'un élément présente une erreur
Trois interrupteurs sous la politique par défaut de l'organisation transforment les échecs en tâches de suivi pour chaque projet. Chaque interrupteur active une automatisation listée dans l'Usine sous Automatisations ; l'agent lit le code et ouvre une tâche, qui suit ensuite les mêmes étapes de spécification, de construction, de vérification et de révision que toute autre tâche.
| Interrupteur | Quand | Ce que fait l'agent |
|---|---|---|
| En cas d'échec d'une tâche, ouvrir une tâche de correction | Une tâche échoue | Il détermine la cause et, si celle-ci réside dans le code, ouvre une tâche pour la corriger. |
| En cas d'échec d'une déploiement, enquêter | Un déploiement échoue | Il analyse les modifications apportées dans cette version et ouvre une tâche indiquant ce qui a mal tourné et ce qu'il faut modifier. |
| En cas de retour arrière sur une version, planifier la correction | Une version subit un retour arrière | Il ouvre une tâche qui consigne ce qui a été renvoyé en arrière, pourquoi, et ce qui doit être modifié avant une nouvelle mise en production. |
Désactiver un automate le met en pause ; le réactiver le relance. Chaque modification permet de l'annuler. La page de cet automate dans l'usine indique qu'il est géré par le Contrôle qualité. Le mettre en pause sur cette page équivaut à le désactiver ; modifier ses instructions en fait votre version personnelle après confirmation, et l'interrupteur ne pourra plus l'activer ou le désactiver.
Il s’agissait de modèles dans Nouveau travail. Une automatisation que vous avez créée à partir de l’un d’eux auparavant continue de fonctionner. Si vous ne l’avez jamais modifiée, activer l’interrupteur correspondant la reprend en charge au lieu d’en lancer une deuxième. Si vous l’avez modifiée, elle reste à vous : son nom apparaît sur la ligne de l’interrupteur, et vous pouvez l’adopter pour que l’interrupteur la gère.
Déploiement en toute sécurité
Le problème lié aux portes de contrôle n'est pas qu'elles soient trop faibles, mais qu'une porte de blocage bien intentionnée bloque toutes les tâches de l'organisation en même temps.
Une séquence sécurisée :
- Ajoutez la porte de contrôle en tant que Conseil.
- Laissez-le exécuter sur des tâches réelles pendant une ou deux semaines. Consultez les alertes qu'il génère.
- Ajustez-le en fonction de ce que vous avez appris.
- Promouvoir à Bloquant sur un projet.
- Déployez-le plus largement une fois qu'il fonctionne correctement.
- 1Ajouter la porteConseil
- 2L'observer pendant une ou deux semainesConseil
- 3L'ajuster en fonction de ce qu'elle signaleConseil
- 4Bloquer sur un projetBlocageUn projet
- 5Déployer plus largementBlocagePlusieurs projets
Gestion des versions et restauration
Les politiques sont versionnées. Chaque bascule publie une nouvelle version, et sa confirmation permet de l'annuler en revenant à la version précédente ; les anciennes versions peuvent être restaurées depuis l'historique des versions de l'éditeur avancé.
La restauration est la raison pour laquelle vous pouvez être décisif dans vos publications. Si un nouveau portail de blocage s'avère mal réglé, la restauration ne nécessite qu'une seule action, plutôt qu'un long processus d'analyse.
Surcharges
Une personne ayant l'autorité peut surcharger un portail de blocage. Cette surcharge est enregistrée : qui, quand et contre quoi elle a été appliquée.
Surveillez votre taux de surcharges. Un portail surchargé la plupart du temps qu'il est déclenché ne fait plus respecter aucune règle : il génère seulement des frictions et un historique papier. Il faut soit corriger le portail, soit l'abandonner.