Skip to main content
Los monorepos y los espacios de trabajo con varios paquetes requieren atención adicional en los blueprints, ya que distintos subdirectorios pueden usar diferentes lenguajes, gestores de paquetes o conjuntos de dependencias. Devin admite dos enfoques:

Espacios de trabajo nativos (recomendado)

Crea un blueprint independiente para cada subdirectorio. Cada espacio de trabajo tiene sus propias secciones de initialize, maintenance y Knowledge, con el directorio de trabajo configurado automáticamente en ese subdirectorio.

Subshells

Ejecuta comandos en subdirectorios dentro de un solo blueprint usando (cd dir && command). Es una opción más sencilla para monorepos pequeños con solo unos pocos paquetes.

​
Espacios de trabajo nativos

Recomendado para la mayoría de los monorepos. Los espacios de trabajo nativos asignan a cada subdirectorio su propio blueprint, con una configuración, Knowledge y un directorio de trabajo aislados. Esto es más limpio y más fácil de mantener que usar subshells a medida que aumenta la cantidad de packages.
Con los espacios de trabajo nativos, cada subdirectorio tiene un blueprint dedicado. Los comandos de ese blueprint se ejecutan con el directorio de trabajo ya establecido en el subdirectorio, sin necesidad de cd ni de subshells.

​
El blueprint raíz

Se espera que todo repo que use espacios de trabajo nativos tenga un blueprint raíz. El blueprint raíz se ejecuta desde la raíz del repositorio y lo hace antes que cualquier blueprint específico de un espacio de trabajo. Úsalo para la configuración compartida que se aplica a todo el repo: instalar entornos de ejecución, herramientas globales o realizar instalaciones de dependencias en la raíz. 
# Plantilla raíz — se ejecuta primero, desde la raíz del repositorio
initialize: |
  npm install -g pnpm

maintenance: |
  pnpm install
Los blueprints del espacio de trabajo se encargan luego de la configuración específica de cada paquete y se ejecutan una vez que se completa el blueprint raíz.

​
Crear un workspace

  1. Ve a Settings > Environment > Blueprints
  2. Haz clic en el repositorio
  3. Haz clic en Agregar workspace
  4. Ingresa la ruta del subdirectorio (p. ej., packages/frontend)
  5. Escribe el blueprint para ese workspace
La ruta del workspace debe corresponder a un directorio real dentro del repositorio. Si la ruta no existe cuando se ejecute la compilación, la compilación fallará. Verifica que la ruta coincida exactamente con la estructura de tu repo (p. ej., packages/frontend, no pkg/frontend).

​
Ejemplo

Un monorepo con un frontend en React y un backend en Python. El blueprint raíz instala herramientas compartidas, y luego cada workspace gestiona sus propias dependencias: 
# Blueprint raíz: configuración compartida para todo el repo
initialize: |
  npm install -g pnpm
  curl -LsSf https://astral.sh/uv/install.sh | sh

knowledge:
  - name: structure
    contents: |
      Monorepo con dos packages:
      - packages/frontend — aplicación React (TypeScript, pnpm)
      - packages/backend — API de Python (FastAPI, uv)
Las entradas de knowledge de cada workspace se limitan a ese subdirectorio. Cuando Devin trabaja en packages/frontend, ve los comandos de lint/test/dev del frontend, no los del backend.

​
Cuándo usar workspaces nativos

  • Los subdirectorios tienen lenguajes o gestores de paquetes diferentes
  • Cada paquete necesita sus propias entradas de Knowledge (comandos de lint, test y compilación)
  • Quieres una configuración aislada — si un blueprint falla en un workspace, no bloquea a los demás
  • El número de paquetes está creciendo y un solo blueprint se está volviendo difícil de gestionar

​
Subshells

Para monorepos más sencillos, puedes gestionar todo en un único blueprint usando subshells. Encierra los comandos entre paréntesis para ejecutarlos en un subdirectorio sin afectar a los pasos posteriores: 
maintenance:
  - name: Frontend deps
    run: (cd packages/frontend && pnpm install)
  - name: Backend deps
    run: (cd packages/backend && uv sync)
Los paréntesis (cd ... && ...) crean un subshell. Cuando el subshell termina, el directorio de trabajo vuelve a la raíz del repositorio para el siguiente paso.
Sin paréntesis, cd cambia el directorio de trabajo en todos los pasos posteriores. Usa siempre subshells al cambiar de directorio en los pasos de blueprint.

​
Por qué importan los subshells

Compara estos dos enfoques: 
maintenance:
  - name: Frontend deps
    run: (cd packages/frontend && pnpm install)
  - name: Backend deps
    run: (cd packages/backend && uv sync)
Cada paso se ejecuta desde la raíz del repositorio. Ambos comandos encuentran el subdirectorio correcto dentro de packages/.

​
Cuándo usar subshells

  • El monorepo tiene unos pocos paquetes con una configuración sencilla
  • Todos los paquetes comparten el mismo lenguaje y gestor de paquetes
  • No necesitas entradas de Knowledge específicas para cada paquete

​
Entradas de Knowledge para monorepos

Tanto si usas workspaces nativos como subshells, unas entradas de Knowledge bien estructuradas ayudan a Devin a orientarse en la base de código: 
knowledge:
  - name: structure
    contents: |
      This is a monorepo with three packages:
      - `packages/frontend` — React app (TypeScript, pnpm)
      - `packages/backend` — Python API (FastAPI, uv)
      - `packages/shared` — Shared TypeScript utilities
  - name: frontend
    contents: |
      cd packages/frontend
      Dev server: pnpm dev
      Lint: pnpm lint
      Test: pnpm test
  - name: backend
    contents: |
      cd packages/backend
      Dev server: uv run uvicorn app.main:app --reload
      Lint: uv run ruff check .
      Test: uv run pytest
Una entrada de conocimiento structure que asigne a cada directorio su lenguaje de programación y toolchain ayuda a Devin a navegar por el repo rápidamente. Con los workspaces nativos, cada workspace tiene sus propias entradas de conocimiento, por lo que la entrada structure resulta más útil en el blueprint raíz o en configuraciones basadas en subshells.

​
Ejemplos

​
workspace de Turborepo / Nx

Para workspaces gestionados con una herramienta de compilación para monorepos como Turborepo o Nx, instala las dependencias en la raíz y deja que la herramienta se encargue de la orquestación de cada paquete: 
initialize: |
  npm install -g pnpm turbo

maintenance: |
  pnpm install

knowledge:
  - name: structure
    contents: |
      Turborepo monorepo. Use `turbo` for building and testing:
      - `apps/web` — Next.js app
      - `apps/api` — Express API
      - `packages/ui` — Shared component library
      - `packages/config` — Shared configuration
  - name: build
    contents: turbo run build
  - name: test
    contents: turbo run test
  - name: lint
    contents: turbo run lint
  - name: dev
    contents: turbo run dev

​
Múltiples versiones de JDK

Un monorepo de Java en el que distintos servicios requieren distintas versiones de JDK: 
initialize:
  - name: Install JDK 17 (primary)
    run: |
      sudo apt-get update -qq
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openjdk-17-jdk-headless
      echo 'export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64' \
        | sudo tee /etc/profile.d/java.sh > /dev/null

  - name: Install JDK 11 (legacy service)
    run: |
      sudo DEBIAN_FRONTEND=noninteractive apt-get install -y -qq openjdk-11-jdk-headless

maintenance:
  - name: Warm dependency caches
    run: |
      export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
      (cd services/api && ./gradlew dependencies --refresh-dependencies)

      export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
      (cd services/legacy && ./gradlew dependencies --refresh-dependencies)

knowledge:
  - name: build_api
    contents: |
      Build the API service (JDK 17):
        JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 \
        cd services/api && ./gradlew clean build
  - name: build_legacy
    contents: |
      Build the legacy service (JDK 11):
        JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 \
        cd services/legacy && ./gradlew clean build
  - name: test_all
    contents: |
      Run tests for all services:
        JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64 \
        (cd services/api && ./gradlew test)

        JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 \
        (cd services/legacy && ./gradlew test)

​
Blueprint de org para herramientas compartidas

Si múltiples paquetes de un monorepo comparten las mismas herramientas, instálalas una sola vez en el blueprint de toda la organización: 
# Blueprint de organización (Settings > Environment > Blueprints > configuración de la organización)
initialize:
  - name: Install pnpm
    run: npm install -g pnpm
  - name: Install uv
    run: curl -LsSf https://astral.sh/uv/install.sh | sh
  - name: Install shared build tools
    run: npm install -g turbo typescript
Así, cada blueprint del repo solo necesita comandos específicos del proyecto: 
# Blueprint del repo (usa pnpm y uv del blueprint de org)
maintenance:
  - name: Install all workspace deps
    run: pnpm install
  - name: Install Python service deps
    run: (cd services/ml-pipeline && uv sync)

​
Prácticas recomendadas

Cuando cada subdirectorio tiene su propio lenguaje, gestor de paquetes o proceso de compilación, los workspaces nativos mantienen cada blueprint centrado e independiente. Reserva los subshells para casos sencillos con pocos paquetes.
Cuando uses el enfoque de subshells, encierra los comandos cd entre paréntesis: (cd dir && command). Esto evita que el cambio de directorio de un paso afecte al paso siguiente.
Los entornos de ejecución y los gestores de paquetes que se usan en múltiples repos deben ir en el blueprint de toda la organización. Esto evita duplicaciones y mantiene los blueprints del repo centrados en la configuración específica del proyecto.
Si el paquete A depende de que el paquete B se compile primero, coloca el paso de compilación de B antes del paso de instalación de A en maintenance. Los pasos del blueprint se ejecutan secuencialmente en el orden en que aparecen.
Una entrada de Knowledge llamada structure que asigne directorios a sus lenguajes y herramientas ayuda a Devin a navegar por la base de código. Incluye qué gestor de paquetes usa cada subdirectorio y cualquier dependencia entre paquetes.
En lugar de una sola entrada de Knowledge grande, crea entradas separadas para cada paquete (p. ej., frontend, backend, ml-pipeline). Con workspaces nativos, cada workspace ya incluye su propia sección de Knowledge.
Usa pnpm install (no pnpm install --force) y uv sync (no rm -rf .venv && uv sync). Los comandos incrementales son más rápidos durante las reconstrucciones periódicas.