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.Falta en la lista Además de la base, hay archivos e imágenes en Cloud Storage —fotos de productos y de producción, evidencias de OPR, adjuntos de notas de servicio y documentos de importaciones— que no se incluyen en un backup de PostgreSQL y deben migrarse aparte (ver Parte E). |
| Variables de entorno y credenciales | La lista completa y comentada —qué hace cada variable, cuál es obligatoria y qué
servicio consume— está en Despliegue → A7. Cada repositorio
incluye un .env.example con todas las variables y sin valores reales; los
valores se entregan por canal aparte en el momento del traspaso. |
| 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 del proceso programado. |
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.
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. En la ventana acordada: volcado final de producción, restauración en la base nueva y última pasada de copia del bucket de archivos, para que rutas y objetos queden alineados.
- Proceso programado. Recreación del trabajo de Cloud Scheduler que sincroniza con el ERP en la cuenta nueva (Parte F), y pausa del trabajo antiguo para que no escriba sobre la base durante el corte.
- 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 de los recursos de la cuenta de origen.