> ## 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.

# Escenarios: el crecimiento de ACME Corp

> Cómo evoluciona la configuración de blueprint: desde un solo repositorio hasta una aplicación con múltiples repositorios y dependencias compartidas, y luego hasta una empresa con múltiples organizaciones.

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.

| Etapa                                                                                                      | Cómo es ACME                                                                           | Qué configuran                                                   |
| ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| [1. Un repositorio](#stage-1-one-repository)                                                               | Una sola aplicación Rails, un equipo                                                   | Un blueprint del repositorio                                     |
| [2. Varios repositorios, dependencias compartidas](#stage-2-several-repositories-with-shared-dependencies) | Cinco repositorios, una CLI de desarrollo compartida y servicios que dependen entre sí | Un blueprint de la organización más un blueprint por repositorio |
| [3. Múltiples organizaciones](#stage-3-multiple-organizations-the-enterprise-blueprint)                    | Varios equipos, cada uno con su propia organización, además de un equipo de seguridad  | Un blueprint de Enterprise más blueprints por organización       |

<Info>
  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.
</Info>

***

<div id="stage-1-one-repository">
  ## Etapa 1: un repositorio
</div>

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:

```yaml acme-web (repository blueprint) theme={null}
initialize:
  - name: Install Ruby 3.3
    uses: github.com/ruby/setup-ruby@v1
    with:
      ruby-version: "3.3"

  - name: Install Postgres and Redis
    run: |
      sudo apt-get update -qq
      sudo apt-get install -y postgresql redis-server libpq-dev
      sudo systemctl enable --now postgresql redis-server
      sudo -u postgres createuser -s "$USER"

maintenance:
  - name: Install gems and prepare the database
    run: |
      bundle install
      bin/rails db:prepare

knowledge:
  - name: lint
    contents: bundle exec rubocop
  - name: test
    contents: bundle exec rspec
  - name: startup
    contents: bin/rails server -p 3000
```

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.

<Tip>
  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](/es/onboard-devin/environment/blueprints#getting-started).
</Tip>

***

<div id="stage-2-several-repositories-with-shared-dependencies">
  ## Etapa 2: varios repositorios con dependencias compartidas
</div>

Dos años después, ACME tiene cinco repositorios:

| Repository      | What it is                                                                                                                                                                                                                     |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `acme-devtools` | Una CLI (`acme`) que levanta contenedores, conecta servicios entre sí y sirve nombres de host locales (`acme.local`, `portal.acme.local`). También se encarga de la búsqueda en la documentación interna (`acme docs:search`). |
| `acme-web`      | La aplicación principal. La mayoría de las funcionalidades se implementan aquí.                                                                                                                                                |
| `acme-portal`   | Portal orientado al cliente. Llama a `acme-web`.                                                                                                                                                                               |
| `acme-sso`      | Servicio de autenticación. Ambas aplicaciones dependen de él.                                                                                                                                                                  |
| `acme-events`   | Consumidor de eventos.                                                                                                                                                                                                         |

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.

<div id="one-blueprint-per-application-or-just-one-for-the-development-cli">
  ### "¿Un blueprint por aplicación o solo uno para la CLI de desarrollo?"
</div>

**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.

<div id="the-organization-blueprint">
  ### El blueprint de la organización
</div>

```yaml Organization-wide setup theme={null}
initialize:
  - name: Install Ruby 3.3
    uses: github.com/ruby/setup-ruby@v1
    with:
      ruby-version: "3.3"

  - name: Install Node.js 20
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: Install Docker and Compose
    run: |
      curl -fsSL https://get.docker.com | sh
      sudo usermod -aG docker "$USER"

  - name: Local hostnames for the development CLI
    run: |
      for host in acme.local portal.acme.local sso.acme.local; do
        grep -q " $host$" /etc/hosts \
          || echo "127.0.0.1 $host" | sudo tee -a /etc/hosts > /dev/null
      done

maintenance:
  - name: Authenticate to the internal registry
    run: |
      bundle config set --global https://gems.acme.internal "$ACME_REGISTRY_TOKEN"
      npm config set //npm.acme.internal/:_authToken "$ACME_REGISTRY_TOKEN"

post-build:
  - name: Verify the stack comes up
    run: |
      acme up --detach
      acme status
      acme down
```

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`](/es/onboard-devin/environment/blueprint-reference#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.

<Warning>
  **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](/es/onboard-devin/environment/blueprints#how-builds-work)). 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.
</Warning>

<div id="the-repository-blueprints">
  ### Los blueprints de repositorio
</div>

Cada blueprint de repositorio es pequeño, porque todo lo compartido ya existe:

```yaml acme-devtools (repository blueprint) theme={null}
initialize: |
  ./bin/install            # añade `acme` al PATH para toda la instantánea

maintenance: |
  acme docs:index          # actualiza el índice de documentación interna en cada compilación

knowledge:
  - name: cli
    contents: |
      `acme` manages every local service. Common commands:
        acme up <service>     start a service and its dependencies
        acme status           list running services
        acme docs:search <q>  search internal ACME engineering documentation
      Prefer `acme docs:search` over guessing at conventions.
```

```yaml acme-portal (repository blueprint) theme={null}
maintenance: |
  npm install

knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: startup
    contents: |
      The portal needs SSO running first:
        acme up sso
        acme up portal
      Then visit https://portal.acme.local
```

`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.

<Tip>
  **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.
</Tip>

<Info>
  **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.
</Info>

<Tip>
  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.
</Tip>

<div id="if-your-services-live-in-a-monorepo-instead">
  ### Si, en cambio, tus servicios están en un monorepo
</div>

La idea es la misma, un nivel más abajo: usa [espacios de trabajo](/es/onboard-devin/environment/workspaces) 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.

***

<div id="stage-3-multiple-organizations-the-enterprise-blueprint">
  ## Etapa 3: varias organizaciones — el blueprint de Enterprise
</div>

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.

```yaml Devin's base environment (enterprise blueprint) theme={null}
initialize:
  - name: Corporate certificate authority and proxy
    run: |
      sudo cp "$FILE_ACME_CA_CERT" /usr/local/share/ca-certificates/acme-ca.crt
      sudo update-ca-certificates
      cat <<'EOF' >> ~/.bashrc
      export HTTPS_PROXY=http://proxy.acme.internal:8080
      export NO_PROXY=localhost,127.0.0.1,.acme.internal
      export NODE_EXTRA_CA_CERTS=/usr/local/share/ca-certificates/acme-ca.crt
      export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt
      EOF

  - name: Standard Python runtime
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: Security tooling
    run: |
      pip install bandit safety
      curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

maintenance:
  - name: Point every package manager at Artifactory
    run: |
      pip config set global.index-url \
        "https://devin:$ARTIFACTORY_TOKEN@artifactory.acme.internal/api/pypi/pypi/simple/"
      npm config set registry https://artifactory.acme.internal/api/npm/npm/
      npm config set //artifactory.acme.internal/api/npm/npm/:_authToken "$ARTIFACTORY_TOKEN"

knowledge:
  - name: security-policy
    contents: |
      All dependencies must resolve through artifactory.acme.internal.
      Never add a public registry to a lockfile or a CI configuration.
```

`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`.

<div id="what-each-tier-owns-now">
  ### De qué se encarga ahora cada nivel
</div>

| Nivel            | Responsable                               | Ejemplo de ACME                                                                          |
| ---------------- | ----------------------------------------- | ---------------------------------------------------------------------------------------- |
| **Enterprise**   | Administradores de seguridad y plataforma | Autoridad certificadora, proxy, Artifactory, Python 3.12, escáneres, un token compartido |
| **Organización** | Los administradores de cada equipo        | Payments: Docker, la CLI `acme` y los nombres de host del equipo. Data: Spark y JDK 17.  |
| **Repositorio**  | Quien sea responsable del repositorio     | `bundle install`, `npm install` e instrucciones sobre linting, pruebas y arranque        |

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.

<div id="operating-it">
  ### Cómo operarlo
</div>

* **Actualizar Python de 3.12 a 3.13** requiere editar una sola línea y hacer una [reconstrucción a nivel Enterprise](/es/enterprise/environment-management/overview#enterprise-wide-rebuilds), 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](/es/enterprise/environment-management/rollout).

***

<div id="deciding-where-something-goes">
  ## Decidir dónde va cada cosa
</div>

Recorre la lista. El primer "sí" es la respuesta:

<Steps>
  <Step title="¿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.
  </Step>

  <Step title="¿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`.
  </Step>

  <Step title="¿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.
  </Step>

  <Step title="¿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.
  </Step>
</Steps>

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.

<div id="related-pages">
  ## Páginas relacionadas
</div>

* [Configuración declarativa](/es/onboard-devin/environment/blueprints) — orden de compilación, instantáneas y solución de problemas
* [Referencia de la plantilla](/es/onboard-devin/environment/blueprint-reference) — todos los campos, incluidos `post-build` y `clone`
* [Biblioteca de plantillas](/es/onboard-devin/environment/templates) — blueprints para copiar y pegar según el lenguaje y el registro
* [Workspaces y monorepos](/es/onboard-devin/environment/workspaces) — el equivalente para monorepos de la Etapa 2
* [Descripción general del Environment de Enterprise](/es/enterprise/environment-management/overview) — la Etapa 3 en detalle