Migrar tu empresa

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

Use this file to discover all available pages before exploring further.

Migrar una empresa de la configuración clásica de Environment a la configuración declarativa supone un cambio importante. La página de Rollout ofrece a los administradores de Enterprise un control granular sobre esta transición. Puedes habilitar blueprints para algunas orgs piloto, ampliar el rollout a tu propio ritmo y revertirlo al instante si algo sale mal. La página Rollout presenta un selector de modo de despliegue que controla cómo se ponen los blueprints a disposición de las organizaciones. Hay tres modos, además de un estado inicial antes de que se activen los entornos declarativos: La progresión es: Testing → Disponible → Habilitado de forma predeterminada. Puedes pasar libremente entre Testing y Disponible usando el menú desplegable de modo de despliegue. Sin embargo, Habilitado de forma predeterminada es una acción permanente que no se puede deshacer sin un administrador de Cognition. En el modo de prueba, las organizaciones que no se hayan incorporado siguen usando la configuración clásica y no ven ningún cambio en su experiencia. El administrador de la empresa puede incorporar organizaciones individuales desde la página Rollout. Solo esas organizaciones pasan a la configuración declarativa. Este es el modo base cuando los entornos declarativos se activan por primera vez para una empresa. El modo Disponible agrega un aviso de migración: los administradores de organizaciones que todavía usan la configuración clásica ven un aviso en su página de Configuración de la máquina que los anima a migrar a la configuración declarativa. Esto no cambia su configuración ni les da acceso a todas las páginas de configuración del entorno. Simplemente les informa de que los blueprints están disponibles y les ofrece una vía de autoservicio para incorporarse. Esto es útil para dar visibilidad y permitir que los administradores de organizaciones migren a su propio ritmo. Los administradores de Enterprise pueden anular el estado de implementación para organizaciones individuales directamente en la tabla por organización de la página Rollout:

• En modo Testing o Available: Incluye determinadas organizaciones en blueprints. Estas organizaciones pasan de la configuración clásica a la configuración declarativa de inmediato.
• En modo Enabled by default: Excluye determinadas organizaciones de blueprints para que vuelvan a la configuración clásica. Estas organizaciones continúan usando su configuración clásica.

Las anulaciones son persistentes. Se mantienen aunque haya cambios de modo. Si incluyes una organización en blueprints durante el modo Testing, seguirá en blueprints cuando pases a Available o Enabled by default. Al activar Habilitado de forma predeterminada, un mecanismo de seguridad evita interrupciones: cualquier organización que actualmente use la configuración classic y tenga repositorios configurados recibe automáticamente una anulación explícita de classic. Esto significa que la transición no cambia nada para las organizaciones que están usando activamente la configuración classic. Siguen igual hasta que las migres explícitamente. Las organizaciones sin repositorios (o las organizaciones que ya usan blueprints) no se ven afectadas por esta protección. La mejor manera de abordar esto es crear y validar tu configuración de forma aislada antes de ponerla a disposición de los administradores de la org. No hagas una migración de golpe. Empieza de forma controlada, verifica y luego amplía. Empieza con la empresa en modo Testing. Las orgs no pueden activarlo por sí solas, así que tienes control total.

1. Activa los entornos declarativos para la empresa. Tu administrador de Cognition habilita la función, lo que pone a la empresa en modo Testing.
2. Crea una org de prueba dedicada para probar la configuración del entorno. Esta org existe únicamente para validar tus blueprints.
3. Habilita la configuración declarativa solo para esta org de prueba (mediante una anulación específica por org en la página Rollout).
4. Configura el blueprint de tu empresa: instala todos los entornos de ejecución compartidos, herramientas de seguridad, certificados corporativos, CLI internas, ajustes de proxy y autenticación en el registry. Esta es la capa base que heredará cada org.
5. Configura un blueprint de org para la org de prueba con cualquier herramienta a nivel de org o configuración del registry.
6. Agrega blueprints de repositorio para un conjunto representativo de repositorios. Elige repos que cubran tus stacks tecnológicos más comunes.
7. Verifica de extremo a extremo: inicia sesiones de Devin en estos repos y confirma que todo funcione. Los repos deben clonarse, las dependencias deben instalarse, los comandos de lint/test/build deben ejecutarse correctamente y todas las herramientas deben estar en las versiones esperadas.

Una vez que hayas confirmado que tu pila de blueprints enterprise → org → repo se compone correctamente y genera entornos funcionales:

1. Comunica internamente a los admins de la org que la configuración declarativa ya está disponible y lista para usarse.
2. Cambia al modo Available: cambia el menú desplegable Rollout mode de Testing a Available. Los admins de la org con la configuración clásica ahora ven un aviso de migración que los anima a migrar.
3. Los admins de la org ya pueden migrar sus propias organizaciones. Como el blueprint enterprise ya proporciona la capa base (runtimes, herramientas, certificados y registries), los admins de la org solo tienen que configurar lo específico de su equipo y sus repos.

Cada admin de la org puede usar el asistente de migración para simplificar este proceso. Devin puede inspeccionar la instantánea actual de la org y generar automáticamente una configuración de blueprint equivalente. Consulta Migración a la configuración declarativa para ver el flujo paso a paso. Crea una biblioteca de blueprints de plantilla para tus stacks tecnológicos más comunes (Node.js, Python, Java, Go y monorepos multilenguaje) y compártelos internamente para que los admins de la org no tengan que empezar desde cero. La biblioteca de plantillas es una buena base.

1. Activa Activado de forma predeterminada cuando la mayoría de las organizaciones usen blueprints. Esta es una acción permanente — las organizaciones que usaban la configuración clásica con repos reciben excepciones clásicas automáticas, así que para ellas no cambia nada.
2. Las nuevas organizaciones creadas a partir de este momento empiezan con blueprints de forma predeterminada.
3. Supervisa la página Rollout para ver el estado de las compilaciones en todas las organizaciones. Filtra por “Classic” para ver quiénes aún no han migrado.
4. Trabaja con los admins de las organizaciones restantes para migrar a las que faltan. El asistente de migración hace que este proceso sea sencillo.
5. Elimina las excepciones clásicas una vez que todas las organizaciones estén verificadas en blueprints.

Para las empresas que quieren avanzar rápido, este enfoque minimiza la carga de migración para cada org:

1. Empieza en modo Testing (para que cada org pueda activarse individualmente).
2. Configura primero el blueprint empresarial. Pide a los Admin que configuren el blueprint empresarial con runtimes, herramientas, certificados y configuración del registro compartidos. Esta es la capa base que heredarán todas las orgs.
3. Cambia al modo Available. Esto habilita el aviso de migración para que los Admin de cada org vean una notificación en la página Machine Configuration y puedan migrar por autoservicio.
4. Difunde la documentación a través de los canales internos disponibles (Slack, correo electrónico, wiki) y anima a los Admin de cada org a activarse por su cuenta. El asistente de migración facilita este autoservicio para los Admin de las orgs.
5. Habilita automáticamente las orgs que actualmente tienen 0 repositorios configurados. Estas orgs no tienen nada que migrar; no hay riesgo en cambiarles a blueprints, ya que no tienen una configuración clásica existente que preservar.
6. Migra progresivamente las orgs restantes, una por una. Con el blueprint empresarial ya configurado, cada migración de org solo requiere agregar configuración específica de la org y del repo por encima. Esto es mucho más sencillo que migrar desde cero.
7. Activa Enabled by default una vez que la mayoría de las orgs se hayan migrado. Las nuevas organizaciones creadas a partir de ese momento empiezan con blueprints habilitados.

Este enfoque adelanta la configuración del blueprint empresarial (el trabajo de mayor impacto) y luego permite que las orgs individuales migren a su propio ritmo con un esfuerzo mínimo. Las cosas no siempre salen según lo previsto. El sistema de despliegue admite la reversión en todos los niveles. Los administradores de Enterprise pueden hacer que cualquier org vuelva a la configuración clásica desde la página Rollout:

• La org vuelve de inmediato a usar su instantánea de configuración clásica.
• La configuración clásica se conserva. No se pierde nada cuando una org cambia a blueprints, así que volver atrás es seguro.
• Las sesiones activas no se ven afectadas. El cambio entra en vigor en la siguiente sesión.

Los administradores de Enterprise pueden cambiar libremente entre Pruebas y Disponible usando el menú desplegable del modo de despliegue. Esto resulta útil si quieres pausar la migración de autoservicio mientras investigas un problema. La página Rollout ofrece un panel para hacer seguimiento del progreso de la migración en tu empresa. En la parte superior de la página, las métricas de resumen ofrecen una visión rápida del estado del despliegue:

• Organizaciones con blueprints: Número de organizaciones que actualmente usan blueprints
• Porcentaje de despliegue: Porcentaje de organizaciones con blueprints sobre el total
• Estado general de la compilación: Estado agregado de las compilaciones en las organizaciones con blueprints

Debajo de los KPI, una tabla detallada muestra cada organización: Filtra la tabla por:

• All: Todas las organizaciones de Enterprise
• Blueprints: Organizaciones que actualmente usan blueprints
• Classic: Organizaciones que actualmente usan la configuración clásica
• Overrides: Organizaciones con anulaciones explícitas del estado (en cualquiera de las dos direcciones)

Las transiciones de estado están protegidas frente a cambios simultáneos. Si otro administrador cambia el estado de Enterprise entre que cargas la página y envías tu cambio, la solicitud se rechaza con un error de conflicto. Esto evita sobrescrituras accidentales cuando varios administradores de Enterprise actúan al mismo tiempo. Si tu cambio se rechaza, actualiza la página para ver el estado actual y vuelve a enviarlo si aún corresponde. Todas las transiciones de estado del despliegue se registran en los registros de auditoría:

• Cambios del modo Enterprise (Pruebas → Disponible, activación de Activado de forma predeterminada, etc.)
• Cambios en las anulaciones por org (la org se incluyó, la org se excluyó, se eliminó la anulación)
• Qué Admin realizó el cambio y cuándo

Estos registros están disponibles a través de la interfaz estándar de registros de auditoría de tu empresa.