Le nouveau numéro de GRC Engineer d'Ayoub Fandi aborde les contrôles de gestion des changements qui enregistrent toujours une capture d'écran d'approbation de PR alors que cette approbation elle-même a moins de valeur. La production des agents a augmenté. Le temps de révision, non. La coche verte a toujours l'apparence de 2020. Ce qu'elle atteste, en revanche, n'est plus le même.
Il a raison. Nous ajouterions ceci : la mesure que la plupart des équipes prendront sera de remettre un humain sur la PR. Cela produit toujours la même capture d'écran. Cela n'indique pas ce que l'humain a dû examiner. Et la règle écrite qui précise qui doit réviser la facturation, les paiements ou tout ce qui a un rayon d'impact peut elle-même être commentée dans un correctif urgent que tout le monde sera ravi de fusionner.
La capture d'écran ne permet pas de distinguer les deux années
Une approbation sur une pull request enregistre que le workflow a atteint une étape d'approbation avant la fusion. La capture d'écran n'enregistre pas ce que le réviseur a examiné, le temps qu'il y a consacré ou les règles écrites qu'il a vérifiées. C'est pourtant toujours l'artefact que la plupart des contrôles de gestion des changements demandent à un auditeur d'échantillonner, car c'est l'artefact que la définition du contrôle mentionne toujours.
Ayoub décrit la dégradation à partir des propres rapports de l'ingénierie : plus de production, des PR plus volumineuses, la révision devenant le nouveau goulot d'étranglement. Il cite un article du blog GitHub résumant une étude externe : les modifications réalisées par des agents présentaient plus de redondances et de dette technique, tandis que le sentiment des réviseurs était plus neutre ou positif. La capture d'écran que votre catalogue collecte toujours ne permet pas de distinguer ces deux années. La coche est toujours verte. L'attention derrière celle-ci n'est plus la même.
Remettre un humain ne change pas la preuve collectée
La réécriture tentante consiste à regagner du temps : exiger une personne, réduire le diff, ajouter un autre approbateur. Pour certains changements, c'est la bonne décision. C'est aussi la réécriture qui laisse la définition du contrôle inchangée. Vous collectez toujours une capture d'écran d'une approbation. Vous n'avez toujours pas écrit ce que cette approbation est autorisée à attester.
Le temps de révision restant, lorsque vous l'obtenez, est consacré aux questions que la révision de code connaît déjà. Le correctif urgent est-il correct ? Est-il sûr ? Ce sont de vraies questions. Mais ce ne sont pas la question : 'ce changement vient-il de supprimer la règle selon laquelle une PR de facturation nécessite un propriétaire de domaine ?' Un réviseur qui examine des calculs de facture approuvera la modification de CODEOWNERS comme du bruit.
Le type de changement
Considérez ceci comme illustratif : le type de changement qui soulève la question, et non un incident client. Le correctif urgent dans le reste de la PR peut être propre. Cette ligne est la règle de gestion des changements qui devient fausse.
# domain owners/infra/ @platform-owners-/billing/ @billing-owners+# /billing/ @billing-owners # unblocking the invoice hotfix/docs/ @docs-ownersNi un bug ni une vulnérabilité. CC8.1 concerne la gestion des changements : les modifications doivent être autorisées, révisées et approuvées selon le processus que vous avez consigné. Cette ligne était la révision indépendante pour la facturation. La commenter signifie que la prochaine PR de facturation pourra être fusionnée avec une approbation générique. La capture d'écran existera toujours. La règle écrite selon laquelle les changements de facturation nécessitent un propriétaire de domaine, elle, n'existera plus.
Réécrivez le contrôle, pas seulement les effectifs
Le numéro d'Ayoub est un avertissement : ne défendez pas le rituel de la PR plus fermement simplement parce que la capture d'écran a toujours l'air officielle. Nous sommes d'accord. L'échec supplémentaire est que la réécriture que la plupart des équipes livreront ce trimestre demande toujours cette capture d'écran, et la règle qui définissait la révision peut être modifiée dans une PR que personne n'a lue comme un changement de contrôle.
Si vous réécrivez la gestion des changements pour l'adapter à la vitesse des agents, écrivez ce que 'révisé' est autorisé à signifier, et traitez les modifications de cette définition comme étant dans le périmètre du même contrôle. Un chemin CODEOWNERS, une vérification requise, une exemption CODEOWNERS, un saut dans la protection de branche : ce sont les contrôles. Ce ne sont pas des commentaires de routine sur un correctif urgent.
La position de heygrc
heygrc n'est pas la newsletter, l'atelier, ni un remplacement pour les revues de bugs et de sécurité que vous exécutez déjà. C'est la couche qui lit chaque pull request par rapport aux frameworks que vous avez choisis et au contexte que vous lui avez fourni. Lorsqu'un changement rendrait une règle de gestion des changements ou de chemin de révision difficile à défendre, il le signale sur le diff. Il ne fusionne rien. Il pose la question sur la pull request, avant que l'audit ne prélève une capture d'écran qui ne signifie plus ce que le contrôle prétend qu'elle signifie.
Lisez le numéro d'Ayoub. La dégradation de la capture d'écran est la sienne. La question supplémentaire est : que se passe-t-il lorsque vous réécrivez le contrôle et que vous ne collectez toujours que la capture d'écran ?