Proceso de Revisión de Pull Requests (PRs)
Este documento describe el proceso estándar desde la creación hasta la integración final de un Pull Request (PR) en nuestra empresa, detallando paso a paso para asegurar calidad, claridad y rapidez en la revisión.
- Creación del Pull Request:
- Cada PR debe tener un título claro, breve y descriptivo siguiendo la convención acordada por el equipo.
- La descripción debe explicar detalladamente el objetivo, alcance y las funcionalidades implementadas.
- Etiquetar el PR correctamente (feature, bugfix, improvement, hotfix) para facilitar su organización y seguimiento.
- Asignación de Revisores:
- El desarrollador debe asignar como mínimo un revisor, idealmente dos.
- Se recomienda rotar revisores para fomentar una mayor diversidad de perspectivas, detectar distintos tipos de problemas y promover el aprendizaje cruzado.
- Documentación de Evidencias:
- Frontend: Es obligatorio incluir evidencia visual clara del comportamiento de las pantallas afectadas. Idealmente, un video donde se muestre la interacción con la interfaz en diferentes tamaños de pantalla (responsive). Esto ayuda a validar el diseño y la funcionalidad.
- Backend: Se debe incluir un video utilizando herramientas como Swagger o Postman que demuestre el funcionamiento correcto de los endpoints desarrollados o modificados, evidenciando las respuestas esperadas.
- Proceso de Revisión:
- El revisor debe analizar el código con base en los requisitos, asegurando el cumplimiento de las buenas prácticas, estándares del equipo y claridad del código.
- Validar que se han implementado pruebas adecuadas y que todas las pruebas automatizadas se ejecutan correctamente.
- Confirmar que la documentación (ya sea técnica o en el código) esté actualizada y sea comprensible.
- Brindar retroalimentación clara, constructiva y directamente aplicable. Evitar comentarios ambiguos.
- Aplicación rápida de cambios:
- Las revisiones deben realizarse de forma ágil para no bloquear el flujo de trabajo.
- El desarrollador debe priorizar la atención a los comentarios del PR antes de continuar con nuevas tareas. Esto permite mantener el alcance del PR acotado y evitar introducir cambios no relacionados.
- Iteraciones del PR:
- El proceso puede requerir varias rondas de revisión. El desarrollador debe aplicar los cambios solicitados y notificar al revisor.
- El PR se considera listo para integrarse solo cuando el revisor principal ha dado su aprobación explícita.
- Integración y cierre:
- Una vez aprobado, el PR debe integrarse usando la estrategia definida por el equipo (merge, squash, rebase), según corresponda.
- El desarrollador debe asegurarse de que la integración no genere conflictos ni errores en ambientes de prueba o producción. Se recomienda monitorear el comportamiento posterior a la integración. Recomendaciones adicionales:
- Evitar PRs excesivamente grandes; si el alcance es amplio, dividir en PRs más pequeños y enfocados.
- Mantener una cultura de revisión continua para evitar cuellos de botella y fomentar la colaboración.
- Promover un diálogo constante y respetuoso entre revisores y autores de PRs. Este flujo de trabajo busca no solo asegurar la calidad técnica del producto, sino también fortalecer la colaboración del equipo, la transparencia y la mejora continua en nuestros procesos de desarrollo.