La regla general, de entrada: los blueprints del repositorio instalan las dependencias del proyecto, los blueprints de la organización instalan todo lo que comparten varios repositorios, y los blueprints de Enterprise instalan todo lo que debe tener cada organización. Los niveles son aditivos y se ejecutan de arriba abajo: empresa → organización → clonar repositorios → repositorio.
Etapa 1: un repositorio
acme-web, una aplicación de Rails con Postgres y Redis. Dos ingenieros, un repositorio. Todavía no hay nada que compartir, así que todo va en el blueprint del repositorio.
Agregan el repositorio en Settings > Environment > Blueprints > Agregar, abren el editor y escriben:
acme-web (repository blueprint)
Dos años después, ACME tiene cinco repositorios:
Este es el caso interesante, porque los repositorios no son independientes: en
acme-portal no se puede hacer ningún trabajo útil a menos que acme-devtools esté instalado y acme-sso esté en ejecución. Esto plantea dos preguntas.
”¿Un blueprint por aplicación o solo uno para la CLI de desarrollo?”
- Agrega los cinco repositorios al Environment para que todos se clonen en la instantánea.
- Coloca la configuración compartida entre repositorios una sola vez en el blueprint de la organización: entornos de ejecución, Docker, nombres de host locales y credenciales para el registro interno.
- Dale a cada repositorio su propio blueprint del repositorio para sus propias dependencias y sus propias entradas de
knowledge(comandos de lint, test e inicio).
acme-devtools: los blueprints de repositorio se ejecutan después de que se clonan todos los repositorios, pero sus pasos se ejecutan en el directorio de ese repositorio, y sus entradas de knowledge se cargan solo cuando Devin está trabajando en ese repositorio. Si acme-devtools instalara todo, una sesión que trabaje en acme-portal no vería ninguno de los comandos de lint y test del portal, y un solo paso fallido de acme-devtools haría que los otros cuatro repositorios parecieran estar bien, pero fueran inutilizables.
El blueprint de la organización
Organization-wide setup
-
initializefrente amaintenance. Docker, los entornos de ejecución y los nombres de host forman parte de la configuración única del sistema, por lo que van eninitialize. Las credenciales del registro deben actualizarse en cada compilación periódica, por lo que van enmaintenance. El CLI deacmeno aparece aquí a propósito. Está dentro deacme-devtools, y los pasos de la organización se ejecutan antes de que se clone cualquier repositorio, por lo que se instala desde el blueprint de ese propio repositorio (se muestra a continuación). Esa instalación se ejecuta durante la compilación y se conserva en la instantánea, desde donde cualquier otro repositorio puede usarla. -
post-buildes la gran ventaja de las configuraciones con varios repositorios. Se ejecuta después de que todos los repositorios se hayan clonado y configurado, así que es el único lugar donde puedes validar que toda la pila arranca en conjunto. Un código de salida distinto de cero hace fallar la compilación, por lo que detectas una pila rota en tiempo de compilación en lugar de a mitad de la sesión. Consultapost-build. -
Los secretos pertenecen a la organización, no a cada repositorio. Un
ACME_REGISTRY_TOKENen la pestaña Secrets del blueprint de la organización sirve para elbundle instally elnpm installde todos los repositorios.
Los blueprints de repositorio
acme-devtools (repository blueprint)
acme-portal (repository blueprint)
acme-web, acme-sso y acme-events siguen la misma estructura: un paso de maintenance para sus propias dependencias y entradas de Knowledge para sus propios comandos de lint, test e inicio.
Knowledge es por repositorio. Con cinco repositorios configurados, una sesión que trabaja en
acme-portal ve las entradas de Knowledge del portal, además de Knowledge de la organización y de Enterprise; no ve las entradas de acme-web. Por eso cada repositorio merece su propio blueprint, incluso cuando su sección maintenance tiene una sola línea.Si, en cambio, tus servicios están en un monorepo
Etapa 3: varias organizaciones — el blueprint de Enterprise
- Todo el tráfico pasa por un proxy corporativo, con una autoridad de certificación interna.
- Todos los paquetes provienen de Artifactory, nunca de registros públicos.
- Todos los entornos deben tener instaladas las herramientas de la empresa para analizar dependencias y detectar secretos.
- Python es 3.12 y Node.js es 20 en toda la empresa, sin excepciones.
Devin's base environment (enterprise blueprint)
ARTIFACTORY_TOKEN es un secreto enterprise, definido una sola vez en Settings > entorno base de Devin > Secretos y disponible en todas las compilaciones y sesiones de todas las organizaciones. El certificado es un archivo adjunto que se presenta en la compilación como $FILE_ACME_CA_CERT.
De qué se encarga ahora cada nivel
El blueprint de la organización de Payments de la Etapa 2 sigue funcionando sin cambios. Simplemente ya no necesita instalar Python ni configurar registros, porque el nivel Enterprise ya lo hizo. El blueprint de la organización de Data instala Spark y un JDK, que Payments nunca ve. Los blueprints de repositorio no cambian.
Cómo operarlo
- Actualizar Python de 3.12 a 3.13 requiere editar una sola línea y hacer una reconstrucción a nivel Enterprise, que se propaga a todas las organizaciones.
- Cuando un equipo necesita una credencial diferente — por ejemplo, si la organización de Data tiene su propio realm de Artifactory — ese equipo define un secreto de la organización con el mismo nombre, y anula el secreto de Enterprise.
- Para desplegarlo gradualmente en las distintas organizaciones, consulta Migrar tu empresa.
Decidir dónde va cada cosa
1
¿Lo necesita cada organización de la empresa?
→ Blueprint de Enterprise. Certificados, proxies, registros internos, entornos de ejecución obligatorios, herramientas de seguridad y secretos de toda la empresa.
2
¿Lo necesitan dos o más repositorios de esta organización?
→ Blueprint de la organización. Docker, CLI de desarrollo compartidas, nombres de host locales, orquestación de servicios entre repositorios y credenciales del registro. Valida el conjunto ensamblado en
post-build.3
¿Solo lo necesita este repositorio?
→ Blueprint del repositorio. Instalación de dependencias, migraciones y las entradas de
knowledge para sus comandos de lint, test e inicio.4
¿Es un dato y no un comando que se deba ejecutar?
→
knowledge, en el nivel que corresponda. Nunca se ejecuta; se carga en el contexto de Devin.- Poner todo en el blueprint de un solo repositorio. Los demás repositorios no reciben entradas de
knowledge, y un solo paso roto hace que toda la configuración parezca inestable. - Duplicar herramientas compartidas en cada repositorio. Cuando dos repositorios instalan versiones distintas de la misma herramienta global, prevalece la última en ejecutarse. En su lugar, coloca la herramienta en el blueprint de la organización.
- Omitir la verificación entre repositorios. Cuando tus repositorios solo funcionan juntos,
post-buildes el único lugar donde se demuestra que lo hacen: antes de que empiece una sesión, no durante ella.
- Configuración declarativa — orden de compilación, instantáneas y solución de problemas
- Referencia de la plantilla — todos los campos, incluidos
post-buildyclone - Biblioteca de plantillas — blueprints para copiar y pegar según el lenguaje y el registro
- Workspaces y monorepos — el equivalente para monorepos de la Etapa 2
- Descripción general del Environment de Enterprise — la Etapa 3 en detalle

