mejora: P13 Revisar Pull Request

Topi99 commented 3 years ago

Objetivos

Verificar y validar los cambios del Pull Request (PR).
Medir el estado de calidad del código que se quiere incorporar a través de defectos.

Involucrados

Revisores del PR (miembros del equipo).
Dueño del PR.

Entradas

Un PR listo para revisión.

Etapas y descripciones

Etapa	Actividad	Encargado	Práctica del CMMI
Pre revisión.	De acuerdo al checklist del dueño del PR definido al escribir la descripción, realiza la verificación de los items escritos. Si algo no se encuentra presente, registra el defecto en el Defect Log actual y corrige a la brevedad.	Autor del PR.	VER1.1, M&A2.1, M&A2.3
	Determina qué entorno de verificación será usado en estas revisiones. Los entornos pueden estar en Heroku (el enlace se deberá proveer en la descripción del PR) o en local (con instrucciones de cómo probar y verificar los cambios en la descripción).		VER2.1, CM2.1
	Comunica con el equipo de trabajo que tienes un PR listo para revisión. Solicita a mínimo 2 compañeros que realicen la revisión de tu PR. Asigna a los revisores en el PR, en la sección de "Reviewers (Revisores)".		VER2.2
Revisión estática	Lee la descripción del PR para saber más sobre los nuevos cambios a línea base del producto de trabajo. En la descripción encontrarás el enlace al ticket con los criterios de aceptación, entre más datos.	Team member.	VER1.3, VER2.1
	Para identificar los componentes relacionados, revisa la pestaña "Files Changed (Archivos cambiados)" del Pull Request. Los archivos marcados con rojo y/o verde son los que necesitan una revisión.		VER1.1
	Abre el ticket relacionado al PR (el enlace debería estar en la descripción del PR, en la sección de "tickets relevantes".), entiende los criterios de aceptación y cualquier diagrama o modelo proporcionado en el ticket, servirán para realizar la verificación del cambio.		VER1.1
	Realiza una revisión del código de acuerdo al checklist propuesto por el encargado del PR en la descripción del mismo. Si algo se cumple, marca la casilla correspondiente. Realicen esto en parejas para mejorar la detección de defectos. Registra cualquier defecto en el Defect Log.		VER1.2, M&A2.1, M&A2.3
	Si hay modelos del código presentes en el ticket, verifica que estén implementados de manera correcta.		VER2.2, VER3.1
Revisión con el cambio corriendo.	Si el ambiente de verificación/validación es local, descarga los cambios, aplica migraciones y cualquier otra configuración establecida en la descripción del PR. Si el ambiente es en la nube, solamente abre el link proporcionado.		VER1.2, CM2.1
	Verifica que los criterios de aceptación estén presentes y se cumplan. Si alguno no se cumple, registralo en el Defect Log actual.		VER3.1, M&A2.1, M&A2.3
	Verifica que los modelos de interfaz gráfica se cumplan. Si alguno no se cumple, registralo en el Defect Log actual.		VER3.1
Post revisión.	Si encontraste defectos, una vez registrados en el Defect Log, solicita cambios en el PR para que sean atendidos por el dueño a la brevedad, comunicando los defectos registrados en el Defect Log. Puedes revisar el Proceso para gestionar métricas si es necesario.		VER2.3, M&A2.4
	Analiza los resultados de las métricas y toma decisiones a partir de esto. Se recomienda que el análisis sea semanal para tener suficientes datos. Puedes revisar el Proceso para gestionar métricas si es necesario. También, consulta la guía de análisis de defectos.		VER3.2, M&A2.4
	Si no se encontraron defectos, aprueba los cambios del PR para poder hacer merge y hacer deploy a staging (si aplica).		M&A2.4

Salidas

Posible aprobación de PR.
Posibles cambios solicitados al PR.
Posibles nuevas entradas al Defect Log.

Referencias

Proceso para gestionar métricas

Topi99 commented 3 years ago

@Solify-IT/wiki-owners

LaloGlzMlz commented 3 years ago

Lo veo bien, solo opino que para hacer más corto cada paso del proceso, podríamos evitarnos algunas descripciones dentro de los pasos y hacer esa parte en una guía que vaya de la mano con el proceso.

En cuestiones de formato solo veo que la etapa "Pre-revisión" está dos veces.

albertcastaned commented 3 years ago

Lo veo bien. Esto falta por determinar pero los archivos modificados se agregarían a la matriz de trazabilidad al crear el PR? O durante la codificación? Si seria en el PR podríamos ponerlo como etapa

stale[bot] commented 3 years ago

Este issue ha sido marcado automáticamente como "bottleneck" porque no ha tenido actividad reciente. El issue sera cerrado si no ocurre alguna actividad en el issue.

Topi99 commented 3 years ago

@albertcastaned Sí, voy a poner la etapa.

Topi99 commented 3 years ago

Pensandolo bien, no lo voy a añadir. Este proceso es solo para revisar un PR. El mejor lugar sería en el proceso para crear el PR.

Solify-IT / docs