Une politique est un ensemble nommé et versionné de portes 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, l'emplacement des portes dans une exécution – lisez Portes 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 commutateur 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 est bloquant ou consultatif.
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 le reste
- parfois 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 commutateurs. Ce changement lui donne sa propre configuration, copiée de la politique par défaut, et les modifications ultérieures de celle-ci n'auront plus d'effet sur lui. 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 commutateurs, 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 comme votre standard vérification, celles que la plupart des projets devraient exécuter, pas votre politique la plus stricte – la plus stricte doit être choisie 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 Contrôle qualité décide de leur sort, pour la politique par défaut de l'organisation et pour chaque projet :
- Coroid Contrôle qualité exécute les vérifications ci-dessus sur chaque pull request et signale le résultat comme la vérification Coroid Contrôle qualité sur GitHub.
- Coroid Révision fait en sorte que le lecteur Coroid examine chaque pull request et commente les lignes qu'il remet en question. Il lit les demandes de fusion que Coroid Contrôle qualité a vérifiées.
Paramètres de Coroid Révision :
- Ce qu'il publie. Le mode consultatif, par défaut, commente sans jamais faire échouer la vérification, à une exception près : un problème de sécurité critique ou élevé confirmé entraîne son échec lorsque la Sécurité impose une révision de sécurité (voir Analyse de code et révision de sécurité). Le mode bloquant modifie le comportement en cas de problème, et la vérification échoue alors. Rendez la vérification Coroid Révision obligatoire dans GitHub si une révision bloquante doit empêcher la fusion.
- Quelles demandes de fusion. Par défaut, il attend que le brouillon soit marqué comme prêt, et ignore les demandes de fusion ouvertes par Coroid, car le lecteur Coroid les a déjà examinées dans le cadre de la tâche. Il peut également ignorer les demandes de fusion provenant de bots.
- Quand il effectue la révision. Il attend une période de calme après le dernier transfert, cinq minutes par défaut. Un nouveau transfert annule une révision non commencée. La commande Re-exécuter sur GitHub lance immédiatement une révision.
- Profondeur de la révision. La quantité que le lecteur peut lire et écrire lors d'une révision.
Il suit les règles de révision de Coroid et celles de votre dépôt
review-rules Le dossier. 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.
En cas de dysfonctionnement
Trois commutateurs sous la politique par défaut de l'organisation transforment les échecs en tâches de suivi pour chaque projet. Chaque commutateur lance une automatisation, listée dans Usine sous Automatisations ; l'agent lit le code et ouvre une tâche, et cette tâche suit le même processus de spécification, construction, vérification et révision que toute autre.
| Commutateur | Quand | Action de l'agent |
|---|---|---|
| En cas d'échec d'une tâche, ouvrir une tâche de correction | Une tâche échoue | Détermine la cause et, si celle-ci se trouve dans le code, ouvre une tâche pour la corriger |
| En cas d'échec d'une déploiement, enquêter | Une déploiement échoue | 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 est renvoyée en arrière | Ouvre une tâche qui enregistre ce qui a été annulé, les raisons et ce qui doit être modifié avant sa 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 à cet endroit équivaut à le désactiver ; modifier ses instructions en fait votre version 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 continue de s’exécuter. Si vous ne l’avez jamais modifiée, activer l’interrupteur correspondant la reprend en gestion au lieu d’en lancer une deuxième. Si vous l’avez modifiée, elle reste la vôtre : son nom apparaît dans la ligne de l’interrupteur, et vous pouvez l’adopter pour que l’interrupteur la gère.
Déploiement sécurisé
Le mode de défaillance lié aux portes de contrôle ne réside pas dans leur faiblesse : c'est plutôt 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 Avis.
- Laissez-le fonctionner sur des tâches réelles pendant une ou deux semaines. Consultez les éléments qu'il signale.
- 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 annulation
Les politiques sont versionnées. Chaque commutateur 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é.
L'annulation est la raison pour laquelle vous pouvez vous permettre d'être décisif lors du déploiement. Si un nouveau portail de contrôle s'avère mal réglé, revenir en arrière ne nécessite qu'une seule action au lieu d'une véritable chasse aux archives.
Dépassements
Une personne ayant l'autorité peut dépasser un portail de contrôle bloquant. Ce dépassement est enregistré : qui, quand et contre quoi.
Surveillez votre taux de dépassements. Un portail de contrôle qui est dépassé à chaque fois qu'il se déclenche ne fait plus aucune contrainte : il génère uniquement des frictions et un historique papier. Il faut soit corriger le portail, soit l'abandonner.