¿Qué es una solicitud de extracción?

Una solicitud de extracción (PR) es un método para proponer cambios en una base de código. Los desarrolladores de software bifurcan el repositorio de código principal en una ramificación separada, asignan código a esa ramificación mientras trabajan y crean una solicitud de extracción para marcar sus cambios sugeridos para la revisión del código antes de extraer o fusionar los cambios de la ramificación en el código base principal.

Las PR son mecanismos comunes en los repositorios de Git, como Bitbucket y GitHub. GitLab aplica el término “solicitud de fusión” en lugar de solicitud de extracción para el mismo proceso.

Los desarrolladores pueden crear solicitudes de extracción mediante la interfaz de línea de comandos (CLI) o la interfaz web. Por lo general, se abren nuevas solicitudes de extracción para arreglos, actualizaciones de dependencias, nuevas característica o código refactorizado. Las solicitudes de extracción agilizan las revisiones de código, mantienen las bases de códigos al nivel estándar y promueven la colaboración entre los miembros de los equipos de desarrollo de software.

Las PR permiten a los desarrolladores crear código fuente y probarlo localmente. Dado que los cambios de código están aislados de la ramificación principal, los desarrolladores no necesitan preocuparse por averiar todo el código base.

La metodología de solicitud de extracción implica tres roles vitales que se aplican principalmente a proyectos de código abierto, pero también pueden ser adoptados por proyectos propietarios o de código cerrado:

• Responsables del mantenimiento: los responsables del mantenimiento del proyecto gestionan el proyecto, y a menudo son propietarios de este, y tienen la autoridad para aprobar e integrar las PR o rechazarlas.

• Revisores: estos miembros del equipo (que pueden ser los propios responsables del mantenimiento u otros colaboradores activos con amplia experiencia en el proyecto) revisan los cambios propuestos para garantizar la calidad del código y sugieren mejoras según lo consideren oportuno.

• Colaboradores: estos desarrolladores tienen la tarea de realizar cambios y abrir solicitudes de extracción.

La creación de solicitudes de extracción generalmente implica un procedimiento de siete pasos:

1. Un colaborador bifurca el repositorio principal para crear una nueva ramificación (mediante el git checkout comando o la interfaz web) y clona esta ramificación en su máquina local.
   
   
2. El colaborador trabaja en sus cambios y confirma el código localmente en la ramificación.
   
   
3. Una vez que el colaborador ha terminado y probado su código, primero extrae las últimas actualizaciones del repositorio principal para evitar cambios conflictivos antes de enviar su código.
   
   
4. El colaborador abre una nueva solicitud de extracción para que los cambios propuestos se integren en la ramificación principal.
   
   
5. Los revisores reciben notificaciones cuando se envían solicitudes de extracción. Verifican la PR para comparar las diferencias entre la ramificación del colaborador y la ramificación principal, revisando el código y realizando comentarios en las áreas que necesitan optimización o mejora.
   
   
6. Los colaboradores realizan confirmaciones adicionales basadas en las sugerencias y solicitudes de cambio del revisor.
   
   
7. Cuando se han implementado todos los cambios, el revisor notifica al responsable del mantenimiento, quien aprueba la PR. A continuación, la PR se fusiona con el repositorio principal.

Los equipos de desarrollo de software pueden elegir entre una serie de opciones de flujo de trabajo de PR en función de sus necesidades. Los flujos de trabajo comunes de PR incluyen:

• Flujo de trabajo de la ramificación de características

• Flujo de trabajo de bifurcación

• git-flow

• Flujo de trabajo apilado

Cada nueva característica tiene su propia ramificación dedicada con un nombre descriptivo para resaltar el propósito de la característica. Una vez que la característica esté terminada, los desarrolladores pueden fusionar la ramificación de la característica con la ramificación principal y crear una PR.

Este flujo de trabajo mantiene la estabilidad de la ramificación principal, ya que los colaboradores trabajan por separado en las características. Pero gestionar varias ramificacións de características puede resultar complicado.

El procedimiento de siete pasos descrito en la sección anterior sobre la creación de PR corresponde a un flujo de trabajo de bifurcación. Los proyectos de código abierto suelen utilizar este flujo de trabajo, que además complementa las prácticas de integración continua y entrega continua (CI/CD). El flujo de GitHub sigue un proceso similar al del flujo de trabajo de bifurcación.

El ingeniero de software Vincent Driessen formuló git-flow en 2010. Normalmente se usa para crear software con calendarios de lanzamiento rigurosos o para otros que admiten varias versiones.

Este flujo de trabajo sigue un modelo de ramificación compuesto por estas ramificaciones:

• main contiene la última versión estable

• develop actúa como una ramificación de integración para arreglos, características y otros cambios de código incluidos en la próxima versión

• feature utiliza el desarrollo como su ramificación de origen y ramificación de destino, con características fusionadas en desarrollo cuando están listas

• release se bifurca desde desarrollo y se etiqueta con el número de versión para la próxima versión, y luego se fusiona tanto en desarrollo como en principal una vez que está en condiciones de enviarse

• hotfix se bifurca directamente desde principal para solucionar cualquier problema de producción de alta prioridad o gravedad, y luego se fusiona tanto en desarrollo como en principal tan pronto como se realizan los arreglos

Los desarrolladores crean PR para hotfix , feature y release ramificaciones que necesitan revisión.

Un flujo de trabajo apilado desglosa las tareas grandes en una secuencia de pequeños cambios de código incrementales. El siguiente cambio de código depende del anterior, por lo que las PR se construyen unas sobre otras.

Considere una característica que implica cambios en estas funciones: la base de datos o el modelo de datos, la API y el front end. En la ramificación de características convencional o el flujo de trabajo de bifurcación, un colaborador debe esperar a que la PR de la base de datos o los cambios en el modelo de datos se revisen, aprueben y fusionen en la ramificación principal antes de poder comenzar con las actualizaciones de la API. En un flujo de trabajo apilado, este periodo de espera se elimina: el colaborador puede ramificarse a partir de los cambios en la base de datos o en el modelo de datos para comenzar a trabajar en la API, enviar una PR para eso y ramificar los cambios de API para abordar las tareas de front end.

Las PR ofrecen estos beneficios:

• Fomenta la colaboración

• Mejora la calidad del código

• Aumente la transparencia

• Fortalece las habilidades de programación

Las PR fomentan la cooperación, animando a los miembros del equipo a colaborar independientemente de su rol. Las PR facilitan el feedback y cómo abordarlo, fomentan debates y dan lugar a ideas para refinamientos.

Las PR marcan el inicio del proceso de revisión de código, ya que ayudan a detectar errores, desviaciones respecto al estilo y las normas de programación, problemas de rendimiento y vulnerabilidades de seguridad. Esta supervisión adicional mantiene o incluso mejora la calidad del código.

Las PR permiten a los equipos ver qué cambios se implementaron, quién los realizó, dónde se aplicaron y las razones detrás de ellos. Dicha visibilidad proporciona un mejor insight del estado de la base de código y del proyecto en sí.

Tanto los revisores como los colaboradores pueden aprender unos de otros, adquiriendo nuevas técnicas en el proceso y descubriendo enfoques novedosos para resolver los problemas. Los principiantes y los nuevos miembros del equipo también pueden estudiar las PR anteriores para comprender mejor la base de código y ponerse al día con los estándares de programación y las mejores prácticas del equipo.

Si bien crear PR parece sencillo, aquí hay algunos consejos y trucos que pueden facilitar aún más el proceso:

• Considere borradores

• Los detalles importan

• Mantenga la concentración

• Manténgase al día

• Tome plantillas

Las PR de borrador o las solicitudes de fusión sirven como una vía para que los desarrolladores compartan su trabajo en progreso. Esto permite a los miembros del equipo comenzar las colaboraciones antes e invita al feedback antes para que aquellos que están atrapados en un problema puedan buscar posibles soluciones de sus compañeros de equipo.

Los desarrolladores deben proporcionar mensajes claros, concisos y específicos para sus nuevas confirmaciones. La claridad, la concisión y la especificidad también se aplican a los títulos y descripciones de las PR, lo que facilita y agiliza la comprensión de la intención detrás de los cambios de código.

La agrupación de múltiples problemas en una sola PR puede resultar en tiempos de revisión más largos y más revisiones. Cada PR debe referirse únicamente a una corrección de error o a una característica. Las PR enfocadas pueden conducir a revisiones de código más eficientes.

Antes de impulsar el código y abrir una PR, los desarrolladores deben asegurarse de que su ramificación esté actualizada. Detectar los últimos cambios y cualquier nueva confirmación evita conflictos una vez que se fusiona la PR. Pueden usar el comando git pull para buscar y fusionar cambios de la ramificación de destino o el comando git rebase para un historial limpio de confirmación de git.

Las plantillas de descripción de PR ayudan a garantizar la coherencia y proporcionan un contexto vital para agilizar las revisiones de código. Los equipos pueden crear una plantilla para diferentes tipos de PR, como arreglos de errores, características o código refactorizado.

Las plantillas generalmente se escriben utilizando el lenguaje de marcado Markdown y se colocan en la carpeta raíz o en la ramificación principal del repositorio del proyecto. Los campos típicos incluyen:

• Descripción del problema o característica (con un enlace al ticket correspondiente en Jira u otro software de seguimiento de problemas como referencia)

• Solución que describe en detalle los cambios de código

• Pruebas, como pruebas unitarias o casos de prueba de integración, cobertura de prueba y pasos para validar manualmente la solución, si corresponde

• Cambios en la configuración

• Lista de verificación de tareas relevantes, como documentación de código y compilaciones de código limpio sin errores ni advertencias

La automatización de las PR puede acelerar el ciclo de vida de una PR desde la creación hasta la revisión y la fusión. La automatización de PR abarca una capa de sistemas que ayudan a aliviar cuellos de botella:

• PR apiladas

• Pipelines de CI/CD

• Sistemas de gestión SDLC

• Asistentes de programación impulsados por IA

La mayoría de los repositorios Git no están diseñados para admitir un flujo de trabajo apilado, pero algunas herramientas abstraen la complejidad de sincronizar PR apiladas y gestionar conflictos de fusión. Entre estas herramientas se encuentran la plataforma Graphite, que cuenta con una interfaz de línea de comandos (CLI) y una extensión para VS Code de Microsoft destinada a las PR apiladas, así como una interfaz web para gestionarlas; el sistema de gestión de código fuente Sapling de Meta; y la CLI de código abierto ghstack, que permite enviar diferencias apiladas a GitHub como PR independientes.

Como flujo de trabajo DevOps automatizado, el pipeline de CI/CD ayuda a garantizar la calidad del código. Plataformas como GitHub Actions y GitLab y otras herramientas de CI pueden ejecutar pruebas unitarias y pruebas de integración y desplegar entornos de vista previa que actúan como sandbox para ver y probar cambios de código en PR.

Los pipelines de CI/CD también refuerzan las prácticas de programación seguras. Los analizadores de código estático y otras herramientas de pruebas de seguridad de aplicaciones estáticas (SAST) se integran perfectamente con la mayoría de los entornos de CI/CD para identificar posibles vulnerabilidades de código. Los equipos de DevOps pueden implementar hooks de confirmación previa para la detección de secretos, lo que hace que el escaneo de secretos sea un paso obligatorio antes de que los desarrolladores confirmen el código o inicien PR y bloqueen los cambios que contienen secretos codificados.

Plataformas como Jira e IBM® Engineering Lifecycle Management (ELM) permiten el seguimiento y la gestión de PR a lo largo del ciclo de vida del desarrollo de software (SDLC).

Como parte de la suite ELM, IBM Engineering Workflow Management (EWM) e IBM Engineering Integration Hub integran la automatización de PR directamente en los flujos de trabajo de desarrollo. EWM puede conectarse con repositorios Git a través de los conectores del Hub y activar la creación de PR a partir de elementos de trabajo. Cuando se aprueba un requisito o una solicitud de cambio en EWM, una regla puede abrir automáticamente una PR en el repositorio Git vinculado y rellenar previamente la descripción.

Las automatizaciones impulsadas por IA en ELM también pueden ejecutar análisis estático y suites de pruebas una vez que se abre la PR, enviando resultados de vuelta al elemento de trabajo y bloqueando la fusión hasta que se cumplan los criterios. Mientras tanto, el Hub sincroniza el estado de las relaciones públicas entre las herramientas, reflejándolo en el repositorio y en los paneles de EWM para una visibilidad en tiempo real.

Los asistentes de programación impulsados por IA, como GitHub Copilot e IBM Bob, pueden aumentar los flujos de trabajo de las PR. Por ejemplo, Bob puede generar mensajes de confirmación significativos y bien formateados. Analiza el nombre de la ramificación y el historial de confirmaciones para verificar que se ajusten a las convenciones de estilo del proyecto.

Bob también puede crear una PR directamente desde el IDE de un desarrollador. Analiza el nombre de la ramificación, los cambios de código y el historial de confirmaciones para comprender el propósito y el alcance. Luego genera un título de PR y una descripción detallada que resume los cambios, detectando y utilizando automáticamente las plantillas de PR existentes de un proyecto para las descripciones de las PR.