El nuevo tema de GRC Engineer de Ayoub Fandi aborda los controles de gestión de cambios que aún archivan una captura de pantalla de aprobación de PR, mientras que la aprobación en sí significa menos. La producción de los agentes aumentó. El tiempo de revisión no. La marca verde sigue pareciendo de 2020. Lo que certifica ya no es lo mismo.
Tiene razón. Nosotros añadiríamos esto: el movimiento que la mayoría de los equipos harán será volver a poner a un humano en el PR. Eso sigue generando la misma captura de pantalla. No dice qué tuvo que revisar el humano. Y la regla escrita que indica quién debe revisar facturación, pagos o cualquier cosa con impacto crítico puede comentarse en un hotfix que todos estarán contentos de fusionar.
La captura de pantalla no puede distinguir entre los dos años
Una aprobación en una solicitud de extracción registra que el flujo de trabajo alcanzó un paso de aprobación antes de la fusión. La captura de pantalla no registra qué examinó el revisor, cuánta atención le dedicó o qué reglas escritas verificó. Ese sigue siendo el artefacto que la mayoría de los controles de gestión de cambios piden a un auditor que muestre, porque es el artefacto que la definición del control aún menciona.
Ayoub describe la degradación desde los propios informes de ingeniería: más producción, PR más grandes, la revisión como el nuevo cuello de botella. Señala un artículo del blog de GitHub que resume un estudio externo: los cambios generados por agentes mostraron más redundancia y deuda técnica, mientras que la opinión de los revisores fue más neutral o positiva. La captura de pantalla que tu catálogo sigue recogiendo no puede distinguir entre esos dos años. La marca sigue siendo verde. La atención detrás de ella ya no es la misma.
Volver a poner a un humano sigue generando la misma evidencia
La reescritura tentadora es recuperar el tiempo: requerir a una persona, reducir el diff, añadir otro aprobador. Para algunos cambios, eso es la decisión correcta. También es la reescritura que deja intacta la definición del control. Siguen recogiendo una captura de pantalla de una aprobación. Siguen sin haber escrito qué está permitido certificar esa aprobación.
El tiempo de revisión restante, cuando lo obtienes, se destina a las preguntas que la revisión de código ya conoce. ¿El hotfix es correcto? ¿Es seguro? Esas son preguntas reales. No son la pregunta '¿este cambio acaba de eliminar la regla de que un PR de facturación necesita un propietario de dominio?'. Un revisor que mira los cálculos de la factura aprobará la edición de CODEOWNERS como ruido.
El tipo de cambio
Trata esto como ilustrativo: el tipo de cambio que plantea la pregunta, no un incidente de cliente. El hotfix en el resto del PR puede estar limpio. Esta línea es la regla de gestión de cambios que se vuelve falsa.
# domain owners/infra/ @platform-owners-/billing/ @billing-owners+# /billing/ @billing-owners # unblocking the invoice hotfix/docs/ @docs-ownersNo es un error ni una vulnerabilidad. CC8.1 es gestión de cambios: los cambios deben estar autorizados, revisados y aprobados mediante el proceso que se documentó. Esta línea era la revisión independiente para facturación. Comentarla significa que el próximo PR de facturación puede fusionarse con una aprobación genérica. La captura de pantalla seguirá existiendo. La regla escrita de que los cambios de facturación necesitan un propietario de dominio no.
Reescribe el control, no solo el número de personas
El tema de Ayoub es una advertencia para no defender el ritual del PR con más fuerza solo porque la captura de pantalla sigue pareciendo oficial. Estamos de acuerdo. El fallo adicional es que la reescritura que la mayoría de los equipos implementarán este trimestre seguirá pidiendo esa captura de pantalla, y la regla que definía la revisión puede editarse en un PR que nadie leyó como un cambio de control.
Si estás reescribiendo la gestión de cambios para la velocidad de los agentes, escribe qué está permitido que signifique 'revisado' y trata las ediciones de esa definición como parte del mismo control. Una ruta en CODEOWNERS, una verificación obligatoria, una exención en CODEOWNERS, un salto en la protección de rama: esos son el control. No son comentarios de tareas en un hotfix.
Dónde está heygrc
heygrc no es el boletín, el taller ni un reemplazo para las revisiones de errores y seguridad que ya realizas. Es la capa que lee cada solicitud de extracción frente a los marcos que elegiste y el contexto que le proporcionaste. Cuando un cambio haría que una regla de gestión de cambios o de ruta de revisión sea difícil de defender, lo indica en el diff. No fusiona nada. Plantea la pregunta en la solicitud de extracción, antes de que la auditoría muestre una captura de pantalla que ya no significa lo que el control dice que significa.
Lee el tema de Ayoub. La degradación de la captura de pantalla es suya. La pregunta adicional es qué ocurre cuando reescribes el control y sigues recogiendo solo la captura de pantalla.