Skip to main content
Los blueprints tienen tres niveles —repositorio, organización y empresa— y la pregunta más común es ¿en qué nivel debería ir esto? Esta página responde a esa pregunta siguiendo a una empresa ficticia, ACME Corp, a lo largo de tres etapas de crecimiento. Cada etapa introduce exactamente un problema nuevo, y cada problema se resuelve con el siguiente nivel. Ve directamente a la etapa que más se parezca a tu empresa.
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 tiene un producto: 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)
Esa es toda la configuración. La guardan, se ejecuta una compilación y cada sesión arranca con Ruby instalado, Postgres en ejecución, las gems instaladas y la base de datos migrada. ¿Por qué todavía no hay un blueprint de la organización? Un blueprint de la organización que solo se usa para un repositorio no es más que una indirección. Espera a que un segundo repositorio necesite lo mismo.
ACME no escribió esto a mano. Le pidieron a Devin “configura tu Environment para este repositorio”, revisaron la tarjeta con la sugerencia e hicieron clic en Approve. Consulta Primeros pasos.

Etapa 2: varios repositorios con dependencias compartidas

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?”

Ambos: cumplen funciones distintas. Devin compila una instantánea que contiene todos los repositorios configurados, así que no es una disyuntiva:
  • 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).
Aquí te explicamos por qué no deberías concentrarlo todo en el blueprint de 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
Tres cosas que debes tener en cuenta:
  1. initialize frente a maintenance. Docker, los entornos de ejecución y los nombres de host forman parte de la configuración única del sistema, por lo que van en initialize. Las credenciales del registro deben actualizarse en cada compilación periódica, por lo que van en maintenance. El CLI de acme no aparece aquí a propósito. Está dentro de acme-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.
  2. post-build es 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. Consulta post-build.
  3. Los secretos pertenecen a la organización, no a cada repositorio. Un ACME_REGISTRY_TOKEN en la pestaña Secrets del blueprint de la organización sirve para el bundle install y el npm install de todos los repositorios.
Importante sobre el orden: tanto initialize como maintenance de la organización se ejecutan antes de que se clonen los repositorios (consulta orden de compilación). Cualquier cosa que necesite código fuente ya clonado —como un CLI que está dentro de uno de tus repositorios— debe ir en el blueprint de ese repositorio o en post-build, no en maintenance de la organización. Déjalo en el nivel de organización solo si puedes instalarlo desde un artefacto publicado, como un tarball, un paquete o una imagen de contenedor.

Los blueprints de repositorio

Cada blueprint de repositorio es pequeño, porque todo lo compartido ya existe:
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.
Pon acme-devtools primero en la lista de repositorios. Los blueprints del repositorio se ejecutan en el orden que se muestra en Settings, así que el repositorio que proporciona la CLI compartida debe configurarse antes que los repositorios que la usan.
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.
Como la CLI de acme ya sabe cómo ejecutar todo, la parte más valiosa de estos blueprints es la sección Knowledge: le enseña a Devin qué comando de la CLI debe usar. Apúntala a tu buscador de documentación interna, si tienes uno.

Si, en cambio, tus servicios están en un monorepo

La idea es la misma, un nivel más abajo: usa espacios de trabajo para dar a cada paquete su propia configuración y su propio Knowledge con ámbito propio dentro de un único repositorio, en lugar de un blueprint por repositorio.

Etapa 3: varias organizaciones — el blueprint de Enterprise

ACME ahora tiene 400 ingenieros. Platform, Payments y Data tienen cada uno su propia organización en Devin, con repositorios separados, miembros separados e instantáneas separadas. Un equipo de seguridad tiene requisitos que se aplican a todas:
  • 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.
Nada de esto corresponde a un blueprint de organización, porque habría que copiarlo en cada organización y quedaría desactualizado en cuanto un equipo olvidara actualizarlo. Para eso está el blueprint de Enterprise: un entorno base que se ejecuta primero, en la compilación de cada organización, en toda la empresa.
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

Recorre la lista. El primer “sí” es la respuesta:
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.
Errores comunes que esto evita:
  • 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-build es el único lugar donde se demuestra que lo hacen: antes de que empiece una sesión, no durante ella.