Política de Gestión de Cambios
Política operativa interna. Rige cómo se planifica, revisa, aprueba, despliega y revierte cualquier cambio en los sistemas productivos de Lawra, S.R.L. Aprobada por la Asamblea en [__]. Versión: 1.0.
1. Propósito y Alcance
1.1. Esta política garantiza que los cambios en código fuente, infraestructura, configuraciones y reglas de seguridad sean planificados, revisados, autorizados y documentados antes de su implantación en producción, reduciendo el riesgo de interrupciones, vulnerabilidades y pérdida de datos.
1.2. Soporta el control SOC 2 CC8.1 (Changes to Infrastructure, Data, and Software), que requiere controles formales sobre la implementación de cambios.
1.3. — Aplica a:
- Cambios en el código fuente del sitio web y componentes de IA (repositorio GitHub
lawra-weby repositorios relacionados). - Cambios en reglas de Firestore (
firestore.rules,firestore.indexes.json). - Cambios en Firebase Authentication (proveedores, dominios autorizados, configuración de sesión).
- Cambios en variables de entorno y secretos en producción.
- Cambios en DNS, dominios y certificados TLS.
- Actualizaciones de dependencias con impacto en producción.
- Cambios en configuración de Google Workspace (roles admin, políticas de seguridad).
1.4. — No aplica a: contenido editorial (artículos, traducciones, imágenes) que no afecte la lógica de negocio ni la seguridad de datos.
2. Principios
2.1. — Nada va a producción sin revisión. Todo cambio en código de producción requiere al menos una revisión de par antes del merge.
2.2. — Separación de entornos. El trabajo de desarrollo ocurre en ramas de feature o en entornos de staging; nunca directamente en main.
2.3. — Automatización antes que proceso manual. Los gates automatizados (tests, lint, type-check, escaneo de secretos) son la primera línea de control; la revisión humana complementa, no sustituye.
2.4. — Trazabilidad completa. Cada cambio en producción debe ser rastreable a una decisión de negocio, un Issue o una PR documentada con justificación.
2.5. — Reversibilidad. Todo cambio debe ir acompañado de un plan de rollback explícito, especialmente los de alto impacto.
3. Clasificación de Cambios
3.1. Los cambios se clasifican en tres niveles según su impacto potencial:
| Nivel | Descripción | Ejemplos | Aprobación requerida |
|---|---|---|---|
| Estándar | Cambios de bajo riesgo, predefinidos, reversibles sin impacto material | Actualización de contenido editorial, ajuste de CSS, traducción de strings | PR review por 1 par |
| Normal | Cambios funcionales con impacto en la lógica de negocio o experiencia de usuario | Nueva feature, cambio de reglas de Firestore, actualización de dependencias mayores, cambios en sistema de autenticación | PR review por 1 par + aprobación CTO |
| Mayor / Alto Riesgo | Cambios en seguridad crítica, datos de clientes, infraestructura, o con impacto irreversible | Cambios en permisos de Firestore, migraciones de base de datos, cambio de proveedor de IA, actualización de políticas de Firebase Auth, cambio en configuración DNS | PR review por 2 pares + aprobación Gerente + CTO |
4. Protección de Ramas y Controles GitHub
4.1. — Rama main protegida: La rama main es la rama de producción. Toda escritura directa está bloqueada (branch protection rules activas en GitHub). El despliegue a producción ocurre exclusivamente desde main a través del workflow de GitHub Actions.
4.2. — Reglas de protección obligatorias en main:
- Require pull request before merging: sí.
- Required approvals: mínimo 1 (Normal) / 2 (Mayor).
- Dismiss stale reviews when new commits are pushed: sí.
- Require status checks to pass before merging: sí (ver sección 5).
- Restrict who can push to matching branches: solo roles Admin autorizados.
- Require signed commits: recomendado (activar en cuanto el equipo tenga GPG keys configuradas).
4.3. — Ramas de trabajo:
- Feature branches:
feature/{descripción}ofeat/{ticket-número}. - Bug fixes:
fix/{descripción}. - Hotfixes de producción:
hotfix/{descripción}. - Refactors:
refactor/{descripción}. - Sprints de documentación / legal:
docs/{descripción}.
5. Gates Automatizados (CI/CD)
5.1. Antes de que cualquier PR pueda ser aprobado, deben pasar todos los checks del pipeline de CI configurado en GitHub Actions:
| Check | Descripción | Bloquea merge si falla |
|---|---|---|
| TypeScript type-check | npm run build sin errores de tipos | Sí |
| Lint | ESLint / Astro lint | Sí |
| Tests unitarios (cuando aplique) | npm test | Sí |
| Secret scanning | GitHub Secret Scanning + GitGuardian (si activo) | Sí |
| Dependency audit | npm audit --audit-level=high | Sí |
| Build completo | Compilación de todos los 1,000+ páginas estáticas | Sí |
5.2. El CTO es responsable de mantener los workflows de CI actualizados y de agregar nuevos checks cuando se adopten nuevas herramientas de seguridad.
5.3. — Pagefind index: Tras cada build de producción, el índice de búsqueda se regenera automáticamente. Los deploys fallidos no actualizan el índice.
6. Proceso de Review de Pull Requests
6.1. — Checklist mínimo del autor (PR description debe incluir):
- Descripción del cambio y su propósito.
- Tickets / Issues relacionados (si aplica).
- Tipo de cambio según clasificación (Estándar / Normal / Mayor).
- Pruebas realizadas (manual + automatizadas).
- Plan de rollback (especialmente para cambios Normales y Mayores).
- ¿El cambio afecta datos de clientes? ¿Requiere actualizar DPAs o privacidad? (sí/no + detalle).
- ¿El cambio afecta reglas de seguridad de Firestore? (sí/no).
6.2. — Checklist del revisor:
- ¿El cambio hace lo que dice que hace?
- ¿Hay regresiones posibles?
- ¿Se están manejando errores y casos edge?
- ¿Hay secrets hardcodeados, logs de debug, o PII en el código?
- ¿El cambio afecta la superficie de ataque (nuevos endpoints, nuevas consultas a Firestore, cambios en CORS)?
- ¿El checklist de seguridad del Secure SDLC fue considerado? (ver
secure-sdlc-policy).
6.3. — Plazo de review: Los PRs Estándar y Normales deben ser revisados en máximo 2 días hábiles. Los PRs Mayores en máximo 3 días hábiles. PRs de emergencia: ver sección 8.
7. Aprobación y Despliegue a Producción
7.1. El despliegue a producción ocurre automáticamente al hacer merge a main via GitHub Actions, que ejecuta npm run build y despliega a GitHub Pages.
7.2. — Ventanas de despliegue recomendadas:
- Cambios Normales y Mayores: preferentemente durante horario hábil (lunes–viernes, 9am–5pm ET) para que el equipo esté disponible para monitorear.
- Evitar deploys de cambios Mayores los viernes por la tarde o vísperas de feriados.
- Cambios de emergencia: pueden desplegarse fuera de ventana con notificación explícita.
7.3. — Post-deploy monitoring: Tras cualquier cambio Normal o Mayor, el autor del cambio monitorea el comportamiento en producción durante al menos 30 minutos (revisar Firebase console, logs de error, funcionamiento básico de la UI).
7.4. — Registro de cambios: Cada cambio desplegado a producción queda registrado automáticamente en el historial de commits de Git (fuente de verdad). Adicionalmente, el CHANGELOG del repositorio debe actualizarse con los cambios relevantes para usuarios.
8. Cambios de Emergencia
8.1. — Definición: Un cambio de emergencia es aquel que debe desplegarse fuera del proceso normal para remediar un incidente activo de producción (caída de servicio, vulnerabilidad de seguridad explotada, pérdida de datos).
8.2. — Proceso de emergencia:
- El CTO o Gerente autoriza verbalmente el cambio de emergencia.
- El autor abre una PR con título prefijado
[EMERGENCY]. - Un segundo miembro del equipo técnico (o el CTO si no hay otro disponible) revisa y aprueba expeditamente.
- Los gates de CI se ejecutan igualmente — no se bypasean salvo autorización explícita del CTO documentada en la PR.
- El cambio se despliega inmediatamente tras aprobación.
- Dentro de las 24 horas siguientes: se redacta un post-mortem del incidente y se documenta la justificación del cambio de emergencia en el sistema de gestión de cambios.
8.3. — Registro obligatorio: Todo cambio de emergencia debe quedar documentado con: quién lo autorizó, quién lo revisó, qué problema resolvió, y cuándo se realizó el análisis post-evento.
9. Procedimiento de Rollback
9.1. — Rollback de código (GitHub Pages): Identificar el último commit bueno en Git y ejecutar git revert o crear una PR de rollback que restaure el estado previo. Evitar git push --force a main salvo en casos extremos con autorización del Gerente.
9.2. — Rollback de reglas de Firestore: Las reglas previas se recuperan del historial de Git y se redesplegan mediante el workflow correspondiente.
9.3. — Rollback de configuración de Firebase Auth: Revertir manualmente en Firebase Console los cambios de configuración; documentar los pasos ejecutados.
9.4. — Rollback de dependencias: Revertir el package.json y package-lock.json al commit previo y redeploy.
9.5. Todo rollback ejecutado en producción se documenta como un cambio registrado en el historial, con la razón del rollback.
10. Retención de Registros de Cambios
10.1. El historial de Git en GitHub constituye el registro primario de cambios. Lawra mantiene el repositorio con acceso restringido y sin borrado de historial.
10.2. El historial de PRs mergeadas (incluyendo reviews, aprobaciones y comentarios) se retiene en GitHub por un mínimo de 3 años (o mientras la organización esté activa en GitHub).
10.3. Los incidentes y sus cambios asociados (incluyendo emergencias) se archivan adicionalmente en el sistema de gestión de incidentes / carpeta de cumplimiento SOC 2.
11. Referencias Normativas y Técnicas
- SOC 2 Trust Services Criteria: CC8.1 (Controls over changes to infrastructure, data, and software)
- NIST SP 800-53 Rev. 5 — CM-3 (Configuration Change Control), CM-4 (Impact Analysis)
- ISO/IEC 27001:2022 — Anexo A, Control 8.32 (Change Management)
- Ley No. 53-07 (R.D.) — Crímenes y Delitos de Alta Tecnología
secure-sdlc-policy— Política de Ciclo de Vida Seguro de Desarrolloincident-response-plan— Plan de Respuesta a Incidentes
12. Revisión y Modificación
Esta política se revisa anualmente o ante cambios en la arquitectura técnica o el proceso de despliegue. Modificaciones requieren aprobación del CTO; modificaciones materiales requieren aprobación de la Asamblea.
Próxima revisión: [fecha de adopción + 12 meses].
Adoptada por la Asamblea General de Socios de LAWRA, S.R.L. en fecha [__], conforme consta en el Libro de Actas.
Por LAWRA, S.R.L. — Gerente
Comments
Loading comments...