Pregunta:
En un proyecto tenemos una revisión de código bastante formal, que actualmente se realiza manualmente y se documenta en hojas de Excel y documentos de Word.
Nos gustaría mejorar el proceso de revisión de código actual integrándolo en un flujo de trabajo de Git (utilizando herramientas como Bitbucket Server, que ya tenemos, Gerrit, etc.).
La idea actual es que cada desarrollador implemente funciones y correcciones de errores y cree una solicitud de extracción. Esta solicitud de extracción es revisada por otros desarrolladores y luego se fusiona en nuestra rama de desarrollo principal o no.
Nos gustaría exportar todas las solicitudes de extracción (que ahora son las revisiones de código) para documentarlas formalmente en un documento sin conexión. Este documento de revisión de código es un artículo de entrega para nuestro cliente.
¿Es este un enfoque factible en absoluto?
Respuesta:
Puedes echar un vistazo a Phabricator . Es una buena aplicación de gestión de proyectos de software todo en uno que maneja revisiones de código similares a lo que describió y hace mucho más en torno al desarrollo de software.
No quiero recomendarte una herramienta, pero quiero mostrarte qué idea tienen sobre las revisiones de código, que considero sólida y practicable.
Todo el proceso de desarrollo dentro de Phabricator está documentado, no solo las revisiones de código, porque conecta toda la información utilizando identificadores que se traducen en enlaces automáticamente y producen referencias con fechas, horas y usuarios que participan en las acciones.
Así es como se ve una revisión de código en Phabricator (para abordar su pregunta de manera más específica):
- El desarrollador crea una nueva rama en el repositorio local de git y realiza una confirmación con sus cambios.
- El desarrollador inicia
arc diffpara pelar y probar los cambios y crear una revisión de código (llamada "diferencial"). En este punto, se pueden agregar algunos metadatos. - Phabricator recibe el diferencial y lo pone a disposición de otros desarrolladores en este proyecto.
- Otros desarrolladores pueden comentar el conjunto de cambios y anotarlo. El autor puede actualizar el diferencial.
- Los revisores pueden aceptar o rechazar el diferencial.
- El autor puede entonces abandonar el diferencial o comprometerlo (
arc land). - El repositorio recibe la confirmación y la conecta automáticamente con el diferencial. Y el diferencial también está conectado con el compromiso y / o las acciones que conducen al resultado.
Phabricator se desarrolla muy rápidamente y se desarrolla a su vez en una instancia pública propia de Phabricator .