Pull Requests del Sistema A3¶

Guía para crear y revisar Pull Requests del ERP interno de A Terceros Inmobiliaria.

Antes de Crear un PR¶

✅ Tu código compila sin errores
✅ Los tests pasan
✅ Código formateado con black + isort
✅ No hay secretos en el código
✅ Documentación actualizada (si aplica)

Crear un Pull Request¶

1. Naming de Branch¶

feature/descripcion-corta      # Nueva funcionalidad
bugfix/descripcion-del-bug     # Corrección
refactor/que-se-refactoriza    # Refactorización
docs/que-documentas            # Documentación

2. Template de PR¶

## Resumen
Descripción breve del cambio (1-2 líneas).

## Cambios
- Agregar modelo X
- Actualizar vista Y
- Corregir bug en Z

## Tipo de Cambio
- [ ] Bug fix
- [ ] Nueva funcionalidad
- [ ] Breaking change
- [ ] Documentación

## Testing
Describe cómo probaste los cambios.

## Screenshots
(Si aplica)

## Checklist
- [ ] Código compila
- [ ] Tests pasan
- [ ] No se rompen flujos SPA
- [ ] Imports ordenados con isort
- [ ] Código formateado con black
- [ ] Documentación actualizada
- [ ] No se suben secretos
- [ ] requirements.txt actualizado (si aplica)
- [ ] Migraciones creadas (si aplica)

## Notas Adicionales
Cualquier información relevante.

3. Título del PR¶

Ejemplos: - ✅ feat: agregar módulo de reportes avanzados - ✅ fix: corregir cálculo de comisiones en apartados - ✅ docs: actualizar documentación de API - ❌ cambios (muy genérico) - ❌ fix (sin descripción)

Revisión de PRs¶

Revisores Asignados por Módulo¶

Cada PR requiere mínimo 1 aprobación de un reviewer autorizado:

Módulo/Área	Reviewers Principales
Inventario / Apartados	`[Dev Senior Ventas]`
RH / Checador	`[Dev Senior RH]`
Finanzas / Comprobaciones	`[Dev Senior Finanzas]`
API / Integraciones	`[Arquitecto de Software]`
Frontend / UI	`[Frontend Lead]`
DevOps / Infraestructura	`[DevOps Lead]`
Cambios Arquitectónicos	Requiere aprobación de Tech Lead
Cambios en BD	Requiere aprobación de DBA/DevOps

Nota: Si tu cambio afecta múltiples módulos, solicita review de los reviewers correspondientes.

SLA de Code Review¶

Tipo de PR	SLA de Review	Quién Revisa
Hotfix (P0)	2-4 horas	Tech Lead o quien esté disponible
Urgente (P1)	8 horas	Reviewer asignado
Normal (P2)	24 horas hábiles	Reviewer asignado
Baja prioridad (P3)	48 horas hábiles	Cuando haya capacidad

Si tu PR lleva más de 48 horas sin review: Escalar a Tech Lead en #dev-sistema-a3.

Para Revisores¶

Qué revisar:

Funcionalidad: ¿Hace lo que dice que hace? ¿Cumple requerimientos del ticket?
Código: ¿Sigue estándares de código?
Tests: ¿Tiene tests? ¿Pasan? ¿Cobertura adecuada?
Seguridad: ¿Hay vulnerabilidades? ¿Valida inputs? ¿No expone datos sensibles?
Performance: ¿Hay N+1 queries? ¿Afecta tiempos de respuesta?
Documentación: ¿Está documentado? ¿Docstrings actualizados?
Lógica de Negocio: ¿Es correcta según procesos de A Terceros?

Cómo dar feedback constructivo:

# Evitar
❌ Esto está mal

# Mejor
Línea 45: Podría haber un problema de N+1 queries aquí que afecte
el listado de apartados cuando hay muchos registros.

Sugerencia: Usar `select_related('cliente', 'asesor')` para
optimizar la consulta.

Para Autores de PRs¶

Responder a comentarios: - Implementa cambios solicitados en commits adicionales - Responde con preguntas si no entiendes el comentario - Marca conversaciones como resueltas cuando aplicas cambios - Mantén comunicación profesional - Si no estás de acuerdo, explica tu razonamiento técnico

Re-solicitar review: Después de hacer cambios solicitados, re-solicita review del mismo reviewer.

Aprobar y Mergear un PR¶

Requisitos para Merge¶

✅ Aprobación: Mínimo 1 aprobación de reviewer autorizado
✅ Tests pasan: CI/CD debe estar en verde
✅ Conflictos resueltos: Sin conflictos con la rama master
✅ Branch actualizado: Rebase con master reciente
✅ Revisión de seguridad: No hay secretos, no hay vulnerabilidades obvias

Quién Puede Mergear¶

Desarrolladores Senior: Pueden mergear sus propios PRs después de aprobación
Desarrolladores Junior/Mid: Tech Lead o Senior Dev mergea
Hotfixes: Solo Tech Lead o DevOps
Cambios en Producción: Requiere aprobación de Tech Lead + DevOps

Estrategia de Merge¶

Squash and merge: Para features con muchos commits
Merge commit: Para mantener historial completo
Rebase: Para mantener historial lineal

Deployment Post-Merge¶

Proceso Automático¶

Después de mergear a master:

CI/CD ejecuta tests automáticamente (GitHub Actions)
Deploy automático a Staging si tests pasan
QA en Staging: Equipo de QA prueba funcionalidad
Deploy a Producción: Manual, ejecutado por DevOps

Horarios de Deploy a Producción¶

Horarios Permitidos: - Lunes a Jueves: 10:00 AM - 4:00 PM (hora local) - Viernes: Solo hotfixes críticos (P0) - Fines de semana: Solo en emergencias con autorización

Evitar: - Deploys antes de fines de semana largos - Deploys después de las 4:00 PM - Deploys de features grandes los viernes

Responsable de Deploys: [DevOps Lead - nombre]

Después del Merge¶

Elimina la rama (GitHub lo sugiere automáticamente)
Monitorea Staging: Verifica que el deploy funcionó correctamente
Actualiza ticket/issue: Marca como "En Staging" o "Deployed to Staging"
Notifica en Slack: Menciona en #sistema-a3-deploys si es cambio importante
Monitorea logs: Revisa logs en Heroku por errores después del deploy
Coordina con QA: Si requiere pruebas específicas, notifica al equipo de QA

Si Algo Sale Mal¶

Notifica inmediatamente en #sistema-a3-urgente
Contacta DevOps: [contacto de DevOps]
Evalúa rollback vs hotfix:
Rollback si el problema es crítico
Hotfix si la solución es rápida
Documenta el incidente: Crear postmortem para incidentes mayores

PRs Grandes¶

Si tu PR tiene más de 500 líneas de código modificadas:

Divide en PRs más pequeños siempre que sea posible
Agrega contexto extenso en la descripción del PR
Considera draft PR primero para obtener feedback temprano sobre el enfoque
Documenta arquitectura: Si es cambio arquitectónico, documenta decisiones
Coordina con Tech Lead: PRs muy grandes requieren aprobación del Tech Lead
Más reviewers: Solicita review de 2+ personas para PRs grandes

Draft PRs¶

Usa draft PRs para: - Pedir feedback temprano - Mostrar progreso - Discutir enfoque antes de completar

[WIP] feat: nueva funcionalidad X

CI/CD¶

PRs triggers automáticos: - Formateo de código (black, isort) - Tests (pytest) - Security scans (opcional)

Mejores Prácticas¶

PRs pequeños: Más fáciles de revisar
Un cambio a la vez: No mezclar features con fixes
Tests incluidos: Siempre que agregues código nuevo
Actualiza con main: Rebase frecuentemente
Descripción clara: Ayuda a los revisores

Ver también: - Guía de Desarrollo - Estándares de Código - Testing - Procesos Internos