Convenciones de Git
Usamos commits convencionales (feat:, fix:, chore:) que generan registros de cambios automáticamente. Las ramas se nombran según los tickets: feat/ZENO-123-add-heatmaps.
Los mensajes de commit deben ser imperativos ("Agregar mapas de calor" no "Se agregaron mapas de calor") y explicar el porqué, no solo el qué. El diff muestra qué cambió: su mensaje debe explicar el razonamiento.
Pull Requests
Cada cambio pasa por revisión de código. Los PRs deben ser pequeños, enfocados e incluir contexto para los revisores. Apuntamos a revisiones dentro de 4 horas durante el horario de trabajo.
Requisitos de PR:
- Todas las pruebas pasan
- La verificación de tipos es exitosa
- Al menos una aprobación
- Sin comentarios sin resolver
Las buenas descripciones de PR incluyen: qué cambió, por qué cambió, cómo probarlo y cualquier riesgo o trabajo de seguimiento necesario.
Pipeline de CI/CD
Cada push activa nuestro pipeline de CI: lint, verificación de tipos, pruebas, compilación. Las fusiones a main se despliegan automáticamente en staging. Los despliegues a producción requieren aprobación explícita.
El pipeline se ejecuta en menos de 5 minutos. Si tarda más, lo tratamos como un error a corregir. Los ciclos de retroalimentación rápidos mantienen a los desarrolladores productivos.
Gestión de entornos
Mantenemos tres entornos:
- Desarrollo: Máquinas locales con Wrangler para Workers y Supabase local.
- Staging: Entorno similar a producción en subdominios de staging. Usado para QA final y demostraciones.
- Producción: El entorno real. Desplegado tras la verificación en staging y aprobación explícita.
Migraciones de base de datos
Los cambios de esquema pasan por las migraciones de Supabase. Cada migración debe ser reversible con una migración de descenso correspondiente. Probamos las migraciones en staging con datos similares a producción antes de aplicarlas a producción.
Proceso de lanzamiento
Lanzamos de forma continua. Las funciones entran en producción tan pronto como están listas, protegidas por indicadores de función. Los cambios importantes se anuncian en nuestro registro de cambios con guías de migración claras.
Los indicadores de función nos permiten desplegar código sin habilitarlo para los usuarios. Esto significa lanzamientos más seguros, despliegues graduales y reversiones fáciles si algo sale mal.