Transición
Checklist de traspaso
Qué se entrega, qué tiene que aprovisionar Hermética por su cuenta y en qué orden conviene hacerlo. Organizado sobre los puntos solicitados por el equipo receptor.
1. Punto por punto
| Solicitado | Respuesta |
|---|---|
| Transferencia de los repositorios | Los repositorios ya están en una organización de GitHub, no en cuentas personales. La
transferencia se hace de organización a organización: al agregar al usuario que
administra la organización de origen como propietario temporal en
HERMETICA-SAC, se transfieren ahí directamente. Son dos:
lu-hermetica-comercial-backend y
lu-hermetica-comercial-webapp.No hay servicio intermedio No existe un tercer repositorio: el backend es el servicio que conecta todo. |
| Mapa de arquitectura | Documentado en este sitio, en dos niveles: infraestructura en la nube y módulos de código. El componente central es el backend: el frontend no accede a la base de datos ni a ningún servicio externo. |
| Proveedor de nube y facturación | Google Cloud Platform (cómputo y datos) y Cloudflare (frontend). Ambas cuentas son del proveedor de desarrollo y no se transfieren: alojan también trabajo de otros clientes. Hermética debe crear sus propias cuentas y desplegar allí; la guía de despliegue cubre el aprovisionamiento desde cero. |
| Backup completo de la base | En vez de una copia con fecha —que queda vieja el mismo día— se otorga acceso de
lectura a la base de producción para que el equipo receptor extraiga lo que necesite,
cuando lo necesite y en el formato que prefiera. El repositorio incluye los comandos
dump_production_db y restore_backup_to_local
(ver Parte D). Si aun así se requiere un volcado puntual,
indicar la fecha de corte. |
| Variables de entorno y credenciales | Están en el archivo .env versionado en cada repositorio, de modo que se
transfieren junto con el código. La lista completa y comentada está en
Despliegue → A7. Ver la advertencia de la sección 3. |
| Dominio y DNS | No hay DNS que transferir: no se registró ningún dominio para Hermética. Las
aplicaciones responden hoy en subdominios del proveedor
(hermetica.lumini.dev), gestionados internamente, que se
darán de baja a partir de la fecha de transferencia. Hermética debe apuntar sus
propias aplicaciones a un dominio propio: el procedimiento está en
Despliegue → B3. |
| Documentación técnica de despliegue | Este sitio: guía de GCP y Cloudflare, entorno local, respaldo y restauración de la base, verificación y reversión; más la configuración de los procesos programados. |
2. Qué debe aprovisionar Hermética
Nada de esto se puede transferir: son cuentas y contratos a nombre de quien opere el sistema.
Cuenta de Google Cloud
Proyecto propio con facturación activa. Aloja Cloud Run, Cloud SQL, Cloud Storage, Cloud Build, Artifact Registry y Cloud Scheduler.
Cuenta de Cloudflare
Para el Worker del frontend y el Worker del cron. El plan gratuito alcanza para ambos.
Dominio propio
Un subdominio del dominio corporativo (por ejemplo app.hermetica.pe) para el
frontend, y otro para la API si se quiere evitar la URL de Cloud Run.
Buzón de correo saliente
El sistema envía notificaciones desde despacho@hermetica.pe por SMTP de
Microsoft 365. Es una cuenta de Hermética; hay que confirmar quién administra su contraseña.
Claves de servicios de IA
Anthropic, OpenAI y ElevenLabs, solo si se mantiene la función «Chat Nisira» y la voz. El resto del sistema funciona sin ellas.
Acceso de red al ERP
El backend debe poder alcanzar datawarehouse.hermetica.pe:8050 desde la nueva
infraestructura. Es requisito para la importación.
Rotar todas las credenciales después del traspaso. Las contraseñas de base de datos,
del correo y del datawarehouse están escritas en el código y en el historial de Git, así que
quedan visibles para cualquiera con acceso al repositorio, hoy y hacia atrás. Cambiar el
repositorio de dueño no borra ese historial. Al cerrar el traspaso corresponde rotar la
contraseña de Cloud SQL, la del buzón despacho@hermetica.pe, la del usuario de
Nisira, la SECRET_KEY de Django y las claves de los servicios de IA — y aprovechar
para moverlas a Secret Manager.
3. Orden sugerido
- Accesos. Invitación a la organización de GitHub y transferencia de los dos repositorios.
- Lectura. El equipo receptor recorre este sitio y levanta el entorno local. Es la mejor prueba de que la documentación alcanza: si el proyecto arranca en local sin ayuda, arranca en cualquier lado.
- Datos. Acceso de lectura a la base de producción y primer volcado de prueba con
dump_production_db. - Infraestructura nueva. Aprovisionamiento en la cuenta de GCP de Hermética siguiendo la checklist de puesta en producción, y despliegue del frontend en su cuenta de Cloudflare.
- Corte de datos. Volcado final de producción y restauración en la base nueva, en ventana acordada.
- Procesos programados. Migración del cron de importación (que hoy corre en una laptop) al Worker de Cloudflare y recreación del cron del Portal Gerencial.
- Dominio. Apuntar el dominio propio, agregarlo a
CORS_ALLOWED_ORIGINSy verificar el flujo completo de inicio de sesión. - Cierre. Rotación de credenciales, baja de los subdominios antiguos y apagado del cron de la laptop.
4. Riesgos conocidos que se entregan documentados
| Riesgo | Impacto | Dónde está documentado |
|---|---|---|
| El cron de importación corre en una laptop | Datos congelados sin aviso si la máquina se apaga | Cron |
| Credenciales en el código y en el historial de Git | Acceso a producción para cualquiera con acceso al repositorio | Arquitectura §5 |
AllowAny como permiso por defecto de la API | Todo endpoint nuevo nace público | Arquitectura §5 |
| Bucket de archivos con lectura pública | Evidencias y adjuntos accesibles por URL | Arquitectura §5 |
| Dos lockfiles en el frontend | El despliegue falla aunque todo pase en local | Módulos §5 |
| Precache de la PWA | Los usuarios siguen viendo la versión anterior tras un despliegue | Despliegue B4 |
| El enlace OPR del ERP se completa con semanas de retraso | Órdenes que «no aparecen» en el buscador; es comportamiento de Nisira, no del sistema | Arquitectura §3 |