ISMS Copilot Docs

Política de Gestión de Cambios

ISMS Copilot mantiene una política formal de gestión de cambios para garantizar que todos los cambios en nuestros sistemas de producción sean revisados, probados e implementados de manera segura. Nuestro…

ISMS Copilot mantiene una política formal de gestión de cambios para garantizar que todos los cambios en nuestros sistemas de producción sean revisados, probados e implementados de manera segura. Nuestro proceso equilibra los requisitos de seguridad y cumplimiento con la necesidad de iteración rápida.

Nuestra política de gestión de cambios se integra directamente con nuestro flujo de trabajo en GitHub y la canalización de CI/CD para su aplicación automatizada.

Tipos de Cambios

Categorizamos los cambios en tres tipos según el riesgo y el impacto:

  • Cambios Estándar — Cambios de bajo riesgo y preaprobados, como actualizaciones de documentación, parches de dependencias y actualizaciones rutinarias de configuración. Estos pueden fusionarse automáticamente una vez que pasen las comprobaciones automatizadas.
  • Cambios Normales — Adiciones de funcionalidades, modificaciones en el esquema de la base de datos, cambios en la API y actualizaciones de seguridad. Requieren un proceso de revisión completo con al menos una aprobación antes de la implementación.
  • Cambios de Emergencia — Vulnerabilidades críticas de seguridad, interrupciones del servicio o problemas de integridad de datos. Siguen un proceso de aprobación acelerado, manteniendo un registro de auditoría y una revisión posterior a la implementación.

Flujo de Aprobación

Nuestro proceso estándar de cambios sigue estos pasos:

  1. Creación de Incidencia en GitHub — Solicitud de cambio documentada con justificación y evaluación de impacto
  2. Rama y Solicitud de Extracción — Cambios de código desarrollados en una rama de funcionalidad con una PR descriptiva
  3. Pruebas Automatizadas — La canalización de CI ejecuta pruebas automatizadas que incluyen pruebas unitarias, pruebas de integración y escaneos de seguridad
  4. Revisión por Pares — Al menos un miembro del equipo revisa el código, la arquitectura y las implicaciones de seguridad
  5. Aprobación y Fusión — Los cambios aprobados se fusionan en la rama principal
  6. Implementación Automatizada — Los cambios se implementan automáticamente en producción a través de nuestra canalización de CI/CD (Supabase, Fly.io, Vercel)

Los cambios de emergencia siguen un camino acelerado, pero aún mantienen un registro de auditoría y requieren una revisión posterior a la implementación en un plazo de 24 horas.

Pruebas y Controles de Calidad

Antes de que cualquier cambio llegue a producción, nuestra canalización de CI automatizada aplica:

  • Ejecución de la suite de pruebas automatizadas
  • Validación de migraciones de bases de datos en el entorno de CI de Supabase
  • Análisis estático de código y escaneo de seguridad
  • Verificación de construcción para todos los objetivos de implementación

Reversión y Recuperación

Nuestra política de gestión de cambios incluye procedimientos de reversión para implementaciones fallidas. Mantenemos la capacidad de revertir rápidamente los cambios mientras preservamos la integridad de los datos y la disponibilidad del sistema.

Todos los cambios se rastrean en GitHub con un historial de auditoría completo que incluye aprobadores, marcas de tiempo y justificación del cambio.

Gestión de Secretos y Configuración

Los cambios que involucran secretos, claves API o configuración sensible siguen controles de seguridad adicionales más allá de los procedimientos estándar de cambio para prevenir la exposición de credenciales.

On this page