Cumplimiento de revisión de iguales

Las revisiones de código entre iguales son un componente clave de la entrega de software seguro y compatible. La implementación de referencia de DevSecOps ayuda a imponer la revisión de los cambios de código antes de que se fusionen y pasen a producción.

Gestión de la comprobación de revisión de igual en cadenas de herramientas CI/CD

Esta documentación proporciona instrucciones para habilitar e inhabilitar la comprobación de revisión de igual en la integración continua (CI) y opcional en las cadenas de herramientas de Continuous Delivery (CD).

Cadena de herramientas de integración continua (CI)

De forma predeterminada, la comprobación de revisión de igual está habilitada en la cadena de herramientas de AC. Para modificar este valor:

Para habilitar la comprobación de revisión de igual, establezca el valor de la variable de entorno peer-review-compliance en 1.
Para inhabilitar la comprobación de revisión de igual, establezca el valor de la variable de entorno peer-review-compliance en 0.

Continuous Delivery (CD) Cadena de herramientas

Las variables de entorno siguientes le permiten gestionar la comprobación de revisión de igual dentro de la cadena de herramientas de CD:

Para recuperar una lista de solicitudes de extracción y sus títulos asociados para el despliegue en curso, establezca la variable de entorno peer-review-collection en 1. Tenga en cuenta que esta variable se establece en 1 de forma predeterminada. Para desactivar este listado, establezca peer-review-collection en 0.
Para habilitar la validación de revisión de igual para todas las solicitudes de extracción asociadas con el despliegue actual, establezca la variable de entorno peer-review-compliance en 1. Por defecto, esta variable se establece en 0. Para omitir esta validación, establezca peer-review-compliance en 0.

Puntos importantes

Debe realizar revisiones de igual sólo en la rama protegida (base), que es donde se actualiza el inventario. Si está ejecutando un conducto de AC en una ramificación de característica, establezca la variable de entorno peer-review-compliance en 0 para ese desencadenante específico para impedir la comprobación de revisión de igual en la ramificación de característica.

El cumplimiento de la conformidad con la revisión por pares depende de la finalización de una ejecución de conducto de integración continua (CI) satisfactoria y de la entrada subsiguiente al inventario. Como resultado, la ejecución inicial del conducto de AC omitirá la comprobación de conformidad de revisión de igual.

Para garantizar la conformidad con los estándares de revisión de igual, se presupone que las actualizaciones de inventario en la etapa ci-finish se producen en la rama master. Sin embargo, si las actualizaciones de inventario se realizan en una rama distinta de la maestra, puede establecer la variable de entorno inventory-repo-branch para indicar la rama donde tienen lugar las actualizaciones de inventario.

Se espera que en la cadena de despliegue continuo (CD), todas las actualizaciones de inventario realizadas en el repositorio de inventario sean promovidas a la rama de destino que se está desplegando, asegurando que no se pierda ningún commit. Por defecto, durante el despliegue, el repositorio de inventario se comprobará en la rama de destino. Sin embargo, si su rama de destino de promoción de inventario omite algunos commits entre la rama base y la rama de destino, puede establecer la variable de entorno inventory-repo-branch para especificar la rama base donde se encuentran todos los commits de inventario.

De forma predeterminada, la interconexión de integración continua (CI) realizará automáticamente una confirmación en el repositorio de inventario al final de la ejecución, utilizando el nombre de aplicación como entrada de inventario. Sin embargo, si tiene previsto modificar la entrada de inventario durante la etapa de release, se recomienda incorporar una propiedad de entorno denominada inventory-entry-name en la cadena de herramientas. Esta propiedad debe contener el nombre de inventario modificado para trabajar para el proceso de revisión de igual.

Si tienes una automatización que empuja los commits directamente a tu rama protegida y quieres evitar problemas con las comprobaciones de cumplimiento de revisión por pares, asegúrate de que tu mensaje de commit incluye ##AUTOMATED_COMMIT##.

La implementación de referencia descubre instancias de código que no son revisadas por pares, recopila pruebas y crea incidencias para realizar un seguimiento de estos elementos.

Antes de poder fusionar código en la rama maestra (protegida), el código debe ser revisado por una persona que no haya subido el código modificado.

El repositorio de código (repo) debe tener al menos dos miembros: uno con privilegios de administrador y otro con privilegios de escritura. Si el código se fusiona en un repositorio sin una revisión, la acción debe ser visible en el seguimiento de auditoría del repositorio de códigos. Explore periódicamente el seguimiento de auditoría para identificar y analizar estas situaciones excepcionales.

La canalización recopila datos sobre el cumplimiento de la revisión por pares durante las compilaciones y las implantaciones para crear la pista de auditoría desde las fusiones de solicitudes de extracción/fusión de código hasta las solicitudes de cambio.

En este diagrama, PR1, PR2 son las solicitudes de extracción/fusión que se aprueban antes de la fusión. De forma similar, para PR4, PR5y PR7. Sin embargo, PR3 y PR6, resaltados en rojo, se fusionan sin una aprobación, que es una infracción de conformidad de revisión de igual. Esto se captura como prueba.

De forma predeterminada, la aplicación de ejemplo de la cadena de herramientas de AC intenta establecer el número mínimo de revisores en 1. Si desea cambiar el número de revisores, establezca la propiedad de entorno peer_review_approvers según sea necesario. Para obtener más información sobre cómo establecer el número mínimo de revisores necesarios para una solicitud de extracción/fusión, consulte los siguientes recursos de GitHub y GitLab:

Datos recopilados en ejecuciones de integración continua

Esta colección de datos contiene una lista de todos los commits de las solicitudes pull/merge que se fusionaron en los repos de aplicaciones desde la última compilación.

Los datos de solicitud de extracción se recopilan directamente desde el repositorio de app. Se recopilan los datos de cada solicitud pull/merge relacionada con commits entre el commit del repositorio que activó la compilación anterior y el commit disponible actualmente.

Los commits que no contienen una solicitud pull/merge crean un problema de incidente de conformidad en las siguientes versiones del pipeline. No se puede confirmar directamente en la rama maestra.

Una incidencia de conformidad normalmente contiene la siguiente información:

Lista de URL de solicitud de extracción/fusión para el ID de confirmación asociado.
Repositorio de aplicaciones.
ID de confirmación.
Número necesario de aprobaciones.

Los datos recopilados se guardan como un artefacto de prueba, que se carga en el armario de pruebas, y luego se hace referencia a ellos en las propias pruebas. El resultado final de las pruebas viene determinado por las solicitudes de extracción/fusión aprobadas. Las solicitudes pull/merge no aprobadas, pero fusionadas, no superan este tipo de pruebas.

Datos que se recopilan en las ejecuciones de despliegue continuo

Esta recopilación de datos contiene una lista de todas las solicitudes pull/merge que se fusionaron en repositorios de aplicaciones desde la última implementación.

Los datos de pull request se recogen del almacén de pruebas y del repositorio de incidencias.

El inventario recopila datos de todas las compilaciones en los artefactos relacionados desde el último despliegue.
El archivo de pruebas recopila datos de revisión de iguales almacenados procedentes de las compilaciones.
El repositorio de incidencias recoge información sobre las incidencias de pull/merge request abiertas.

No se accede a los repositorios de app durante esta recopilación de datos. Dado que se supone que las canalizaciones de despliegue continuo se encuentran en entornos aislados, no se pueden cruzar esos límites.

Cambie el contenido de la solicitud

Los datos siguientes se incluyen en la solicitud de cambio generada automáticamente:

Lista de incidentes de solicitudes pull/merge que no se han subsanado. Estos datos incluyen los detalles del activo y la información del incidente ( URL ).

Los incidentes de solicitud de extracción/fusión no subsanados afectan a la disponibilidad de despliegue de la solicitud de cambio. Si se encuentran incidencias de solicitud de extracción/fusión, se consideran vulnerabilidades y la solicitud de cambio debe revisarse y aprobarse manualmente.

Resolución de incidencias de solicitudes de extracción

Las incidencias de solicitudes de extracción se consideran vulnerabilidades porque indican que en artefactos liberados contienen código no comprobado. Para solucionar estos incidentes, lleve a cabo los pasos siguientes:

Revise retroactivamente el cambio fusionado.
Cree un problema sobre cómo solucionar los problemas existentes con el código.
Añada la etiqueta exempt o cierre el problema de incidencia de solicitud de extracción/fusión.

El autor de la solicitud pull/merge y la persona que cierra la incidencia de la solicitud pull/merge no pueden ser la misma persona.

Resolución de problemas

Caso 1:

Problema

La anomalía en collect_peer_review_commits en la etapa prod-start de la interconexión de CD da como resultado que otras etapas fallen con errores. Cuando se produce el siguiente error en la etapa prod_start

| ERROR | 2023-12-20T07:00:48.978Z | index.ts:25:14 | The inventory entry has no such property ('pipeline_run_id').

Solución

Los usuarios que poseen entradas de inventario que no están soportadas por el conducto único deben añadir un archivo de omisión en el inventario. Esta acción garantiza que estos archivos no se tengan en cuenta para ningún cálculo.

Problemas conocidos

La conformidad con la revisión por pares depende de la inclusión de la entrada de inventario en el paso de release después de cada iteración de la interconexión de integración continua (CI). Si se omite la inclusión de la entrada de inventario para cualquier ejecución de conducto de AC anómala, es posible que la prueba de revisión de igual para dicha ejecución de conducto de AC específica se omita en la interconexión de Continuous Delivery (CD).