SAP CPI: CI/CD de cero a héroe – Revisión de código

Este blog es parte de una serie de blogs, por lo que puede encontrar la primera página aquí (https://blogs.sap.com/2023/02/02/sap-cpi-ci-cd-from-from-zero-to-hero/). Esta es la agenda que estamos siguiendo:

Code Review es probablemente su última puerta de calidad antes de lanzar y transportar sus desarrollos a los siguientes entornos, por lo que no necesito convencerlo de la importancia que tiene este paso en la calidad de sus interfaces. A pesar de que hacemos muchas de nuestras comprobaciones automáticamente a través de CPI Lint, lo que ahorra tiempo a nuestros revisores, hay cosas que aún no se automatizaron a través de las reglas de CPI Lint debido a la falta de tiempo. También hay temas que no se pueden automatizar fácilmente y necesitan algo de sentido común y verificación manual.

Tomado de https://www.reddit.com/r/ProgrammerHumor/comments/lxk09d/code_reviews/

Revisión de código: cómo comenzó

Desde el primer día tenemos revisión de código, pero inicialmente fue una tarea bastante informal (a pesar de ser obligatoria). Un desarrollador invitaba a otro, explicaba brevemente los pasos del código, el revisor podía hacer algunas preguntas o brindar algunas sugerencias, pero al final, casi siempre el código se revisaba sin cambios importantes. Si eso te suena sospechoso, también me pareció sospechoso a mí… Después de algunas reflexiones, llegué a algunas conclusiones sobre por qué considero que este es un enfoque defectuoso:

1. El código se revisaba sobre la marcha, con poco margen para la intervención del revisor o incluso el momento adecuado para digerir y pensar en alternativas.
2. No había una lista de verificación estándar sobre qué revisar, por lo que realmente dependía del revisor tener la imaginación para pensar en problemas o escenarios con el código que se estaba revisando.
3. A pesar de que no hay pruebas, sospecho que algunos revisores se sintieron intimidados al proporcionar comentarios en el acto al productor del código.

Tuvimos una sesión de lluvia de ideas sobre esto y, según las revisiones anteriores más la experiencia del grupo, obtuvimos una lista de verificación de los controles obligatorios para revisar (esto resolvería el paso 2 anterior).

Otro resultado fue que invertiríamos en un proceso de revisión de código que sería transversal a nuestros dos equipos (el equipo de CPI que usa Gitea y el equipo de Biztalk que usa TFS).

Revisión del código: cómo evolucionó

Hay muchas herramientas de revisión de código disponibles en el mercado, algunas de ellas integradas en git, lo que significa que puede hacer una solicitud de extracción para fusionar sus cambios en la rama principal y con eso se realiza una revisión de código para validar si su rama puede fusionarse con la rama estable principal. Después de pensar en usar solicitudes de extracción como un enfoque de revisión de código, no vimos ningún beneficio real ya que no haríamos nada con la rama principal después de integrar la solicitud de extracción. Nuestra sincronización de SAP Cloud Integration (CI) a GIT solo ocurre en esa dirección específica, no sincronizamos de GIT a SAP CI porque eso traería problemas adicionales para resolver (bloqueos, conflictos, no más fuente única de verdad, etc. ).

Alguien del equipo sugirió Fisheye+Crucible y después de una evaluación y un POC, todos lo disfrutaron y lo adoptamos para ambos equipos.

Breve introducción a Fisheye

Esta es una herramienta para proporcionar capacidades de búsqueda a su repositorio git desde el tablero de crisol+fisheye. Funciona al sincronizar su repositorio git con un repositorio ojo de pez local, lo que le permite tener un lugar central único para todos sus repositorios de código fuente (Gitea+TFS)

Vista de la lista de repositorios sincronizados en fisheye+crucible

Breve introducción al Crisol

Esta es la herramienta para realizar el proceso de revisión de código en sí. Tiene el concepto de proyectos que servirían como agregadores (creas una reseña para un proyecto). Podría agrupar el código que tendría sentido revisar juntos proveniente de diferentes fuentes. Nos gustaría evitar esta complejidad, por lo que lo hacemos muy transparente al tener un repositorio de ojo de pez para cada paquete de SAP CI y un proyecto para cada paquete de SAP CI y, en consecuencia, el proceso de revisión también es por paquete de SAP CI. Puede tener varias revisiones de código para cada proyecto.

Proyecto Crucible con lista de revisiones.

Pasos del proceso automatizado de revisión de código

A continuación puede encontrar un diagrama de alto nivel sobre los pasos que se realizan hoy en día de forma automatizada.

Pasos del proceso automatizado de revisión de código

1. Lea el código fuente del paquete y 2. Comprométase con git

Este paso ya formaba parte de la canalización y es responsable de cargar el código fuente del paquete de CI cuando la canalización se ejecuta (actualmente a diario) en nuestro servidor git.

3. Crear repositorio Fisheye

AFAIK, Fisheye necesita una copia sincronizada de su repositorio git representado como un repositorio local utilizado por fisheye al realizar las búsquedas que también se utiliza para los procesos de revisión de código. Creamos un repositorio por paquete SAP CI. Solo las confirmaciones que se sincronizaron son visibles en su revisión. Creamos este repositorio local fisheye+crucible si no existe a través de api y también proporcionamos la autorización necesaria (estamos usando la clave ssh) para conectarnos a gitea.

4. y 4a. Activar Git-> Sincronización de ojo de pez

Después de tener un repositorio ojo de pez local, podemos forzar una sincronización incremental (delta). Esto obligará a Fisheye+Crucible a obtener los últimos cambios comprometidos con la sincronización de git en su propio repositorio local. La canalización de Jenkins espera hasta que finalice este proceso

Revisión de código que muestra los cambios en las últimas confirmaciones

5. Crear proyecto de crisol

Como se indicó anteriormente, creamos un proyecto de crisol por paquete SAP CI para mantener la simplicidad, ya que nuestras revisiones se realizan en el paquete SAP CI y no en un nivel superior. Si dicho proyecto aún no existe, creamos uno nuevo. En este nivel puede configurar el propietario (tomamos el paquete identificado como responsable y lo consideramos propietario). Como lista de revisores, todo el equipo de integración de SAP CI puede revisar.

Ejemplo de definición de proyecto

6. Crear revisión de crisol

Verificamos las revisiones existentes para el paquete que estamos procesando. Si existen en Borrador o en Revisión, agregamos los últimos cambios de git allí. Si no existe una revisión abierta pero tenemos archivos git que se confirmaron, abrimos una nueva revisión de código en modo Borrador.

Ejemplo de pantalla de detalles de revisión

7. Agregue archivos comprometidos a la revisión

Finalmente, agregamos estos archivos sin revisar a una revisión existente o recién creada. Luego, durante nuestras llamadas diarias, le pedimos a un colega que haga la revisión y el propietario asigna manualmente al revisor a la revisión abierta automáticamente. Luego, el revisor puede realizar la revisión (necesita verificar el código con la lista de verificación de revisión de código definida) y luego puede agregar comentarios (incluso a nivel de línea).

Revisar comentarios

En el momento del lanzamiento del paquete, verificamos manualmente que todas las revisiones de código de todos los paquetes que queremos transportar estén cerradas (lo que significa que no hay archivos sin revisar).

Valor añadido

Nunca tenemos archivos sin revisar que no sean parte de una sesión de revisión de código. Incluso si cambia un archivo hoy y no lo revisa, si regresara en un año para cambiar otro archivo, el que aún no revisó aún estaría allí para que lo revise. Esto significaría que nos aseguramos de que alguien reconozca y revise cada cambio en cualquier archivo de su paquete cpi en algún momento.

Próximos pasos

• Integre crisol en la tubería de transporte para asegurarse de que no haya revisiones de código en borrador o en revisión para los paquetes que desea transportar
• Verifique una posible integración con JIRA y recopile el revisor de JIRA User Story (US) automáticamente, además de mostrar en JIRA US las revisiones asociadas con

En este tema, introduje el tema de la revisión de código, los desafíos que enfrentamos y cómo evolucionó todo el proceso con el tiempo.

También te invito a compartir algunos comentarios o pensamientos en las secciones de comentarios. Estoy seguro de que todavía hay mejoras o ideas para nuevas reglas que beneficiarían a toda la comunidad. Siempre puede obtener más información sobre la integración de la nube en el página de tema para el producto

Con este post completamos la serie de blogs. Es posible que se pregunte si este enfoque se desvía un poco de lo que suele ver en un enfoque de CI/CD, por ejemplo, la implementación automática de código confirmado probado en otros entornos. De hecho, como no queremos sincronizar desde git de nuevo a CI (por las razones que describí anteriormente), a pesar de que es técnicamente posible, no tiene mucho sentido implementarlo automáticamente desde git. Preferimos tener ese control de nuestro lado evaluando cuándo se realizan las implementaciones en qué entornos y, por lo tanto, activamos los transportes y las implementaciones manualmente después de alinearnos con los equipos funcionales (pero usando las canalizaciones de Jenkins especificadas en el «Gestión de la liberación» página).

Espero que haya disfrutado y se haya inspirado para probar algunas de estas ideas en su cliente/empleador actual. Por favor, hágamelo saber si necesita alguna orientación e intentaré ayudar.