Skip to main content
Esta es la referencia completa de los campos de los blueprints. Para obtener una introducción a los blueprints y cómo se integran en el entorno de Devin, consulta Configuración declarativa del entorno.
Un blueprint define cómo se configura el entorno de Devin: qué herramientas instalar, cómo mantener las dependencias actualizadas y qué comandos debe conocer Devin.

Descripción general

Un blueprint tiene tres secciones principales:
initialize: ... # Instalar herramientas y entornos de ejecución
maintenance: ... # Instalar dependencias del proyecto
knowledge: ... # Información de referencia para Devin (nunca se ejecuta)
SecciónPropósito¿Se ejecuta?
initializeInstalar herramientas del sistema, entornos de ejecución y CLIs globalesSí, durante cada compilación
maintenanceInstalar y actualizar las dependencias del proyectoSí, durante las compilaciones + al inicio de la sesión
knowledgeIndicarle a Devin cómo ejecutar lint, pruebas, compilaciones y otra información específica del proyectoNo, se proporciona como referencia
Las tres secciones son opcionales. Puedes incluir cualquier combinación. initialize se ejecuta solo durante las compilaciones. Los resultados se guardan en la instantánea. maintenance se ejecuta durante las compilaciones (después de initialize) y al inicio de cada sesión tras traer el código más reciente, por lo que los comandos deben ser rápidos e incrementales. Las compilaciones se ejecutan automáticamente cuando cambia tu blueprint y de forma periódica (cada ~24 horas).

initialize

Usa initialize para instalar herramientas y entornos de ejecución que no dependan del estado específico de tu código: entornos de ejecución de lenguajes, paquetes del sistema y CLI globales.

Forma sencilla

Para comandos de shell sencillos, usa un escalar de bloque:
initialize: |
  curl -LsSf https://astral.sh/uv/install.sh | sh
  apt-get update && apt-get install -y build-essential
  npm install -g pnpm

Forma estructurada

Para los pasos con nombre, las variables de entorno o GitHub Actions, usa una lista:
initialize:
  - name: "Install Python 3.12"
    uses: github.com/actions/setup-python@v5
    with:
      python-version: "3.12"

  - name: "Install system packages"
    run: |
      apt-get update
      apt-get install -y libpq-dev

  - name: "Install global tools"
    run: pip install uv
    env:
      PIP_BREAK_SYSTEM_PACKAGES: "1"
Ambas formas pueden combinarse. La forma simple equivale a un único paso con run.

Cuándo usar initialize vs. maintenance

Coloca en initializeColoca en maintenance
Instalación del entorno de ejecuciónnpm install / pip install
Paquetes del sistema (apt-get)bundle install
Herramientas de CLI globalesgo mod download
Configuración únicaActualizaciones de la caché de dependencias
GitHub Actions (setup-python, etc.)Scripts de configuración específicos del repositorio
Ambas secciones se ejecutan en cada compilación, pero esta separación hace que tu configuración sea más legible. Las herramientas y los entornos de ejecución van en initialize; los comandos de dependencias que siguen los archivos de bloqueo de tu código van en maintenance.

mantenimiento

Usa maintenance para instalar dependencias y ejecutar otros comandos que deban ejecutarse después de clonar tu código. Aquí es donde van npm install, pip install, uv sync y comandos similares.
maintenance: |
  npm install
  pip install -r requirements.txt
O de forma estructurada:
maintenance:
  - name: "Install npm dependencies"
    run: npm install

  - name: "Install Python dependencies"
    run: uv sync
    env:
      UV_CACHE_DIR: /tmp/uv-cache
Para los blueprints a nivel de repositorio, los comandos maintenance se ejecutan desde el directorio raíz del repositorio. Para los blueprints a nivel de organización, se ejecutan desde el directorio de inicio (~).

knowledge

La sección knowledge no se ejecuta. Proporciona información de referencia que Devin utiliza cuando trabaja en tu proyecto. Aquí es donde le indicas a Devin los comandos correctos para linting, pruebas, compilación y cualquier otro flujo de trabajo específico del proyecto.
knowledge:
  - name: lint
    contents: |
      Run linting with:
      npm run lint

      For auto-fix:
      npm run lint -- --fix

  - name: test
    contents: |
      Run the full test suite:
      npm test

      Run a single test file:
      npm test -- path/to/test.ts

  - name: build
    contents: |
      npm run build

      Build output goes to dist/
Cada elemento de conocimiento tiene:
CampoTipoDescripción
namestringIdentificador de este elemento de conocimiento (p. ej., lint, test, build)
contentsstringTexto libre con comandos, instrucciones o notas
El campo name es una etiqueta. Por convención, lint, test y build son los nombres estándar. Devin los usa como referencia al verificar su trabajo. Puede agregar cualquier elemento de conocimiento adicional con nombres personalizados:
knowledge:
  - name: lint
    contents: ...
  - name: test
    contents: ...
  - name: build
    contents: ...
  - name: deploy
    contents: |
      Deploy to staging:
      npm run deploy:staging
  - name: database
    contents: |
      Run migrations:
      npm run db:migrate

      Seed test data:
      npm run db:seed

Tipos de pasos

Cada paso de initialize o maintenance utiliza uno de estos dos tipos: comandos de shell (run) o GitHub Actions (uses).

Comandos de shell (run)

Ejecuta cualquier comando de shell en bash:
- name: "Install dependencies"
  run: |
    npm install
    pip install -r requirements.txt
CampoTipoDescripción
namestring (optional)Etiqueta descriptiva del paso
runstringComando(s) de shell que se ejecutarán
envmap (optional)Variables de entorno adicionales para este paso
Detalles de ejecución:
  • Los comandos se ejecutan en bash. Si algún comando de un script de varias líneas falla, todo el paso se detiene de inmediato.
  • Los blueprints a nivel de organización se ejecutan en el directorio de inicio (~).
  • Los blueprints a nivel de repositorio se ejecutan en la raíz del repositorio clonado.
  • Cada paso tiene un tiempo de espera de 1 hora.
  • Los secretos están disponibles automáticamente como variables de entorno.

GitHub Actions (uses)

Ejecuta GitHub Actions basadas en Node.js directamente en tu blueprint:
- name: "Install Python"
  uses: github.com/actions/setup-python@v5
  with:
    python-version: "3.12"
CampoTipoDescripción
namestring (optional)Etiqueta legible para el paso
usesstringReferencia de GitHub Action
withmap (optional)Parámetros de entrada de la acción
envmap (optional)Variables de entorno adicionales para este paso
Formato de la referencia de la acción:
github.com/<owner>/<repo>@<ref>
github.com/<owner>/<repo>/<subpath>@<ref>
Tanto el prefijo github.com/ como el sufijo @<ref> son obligatorios. La ref suele ser una etiqueta de versión como v5. Acciones de uso común:
AcciónPropósitoEjemplo de with
github.com/actions/setup-python@v5Instalar Pythonpython-version: "3.12"
github.com/actions/setup-node@v4Instalar Node.jsnode-version: "20"
github.com/actions/setup-go@v5Instalar Gogo-version: "1.22"
github.com/actions/setup-java@v4Instalar Java/JDKjava-version: "21", distribution: "temurin"
github.com/gradle/actions/setup-gradle@v4Instalar Gradle(ninguno)
github.com/ruby/setup-ruby@v1Instalar Rubyruby-version: "3.3"
Solo se admiten GitHub Actions basadas en Node.js. No se admiten las acciones compuestas ni las acciones basadas en Docker.
Cómo funcionan los valores de with: Los valores que se pasan mediante with se proporcionan a la acción como entradas, siguiendo las mismas convenciones que los flujos de trabajo de GitHub Actions. Todos los valores se convierten en cadenas.
with:
  python-version: "3.12"
  check-latest: true
  cache: "pip"
Cómo las acciones propagan los cambios: Las acciones pueden modificar el entorno para los pasos siguientes. Por ejemplo, setup-python agrega el binario de Python a PATH, que sigue disponible en todos los pasos posteriores y en maintenance.

run vs uses: cuál usar

Usa run cuando…Usa uses cuando…
Instalas paquetes del sistema (apt-get)Configuras entornos de ejecución (Python, Node, Go, Java, Ruby)
Ejecutas scripts específicos del proyectoExiste una acción oficial de GitHub para lo que necesitas
Configuras archivos o el entornoQuieres gestión automática de versiones y almacenamiento en caché
El comando es simple y autosuficienteUsarías la misma acción en un workflow de GitHub Actions
En la práctica, la mayoría de las configuraciones usan uses para los entornos de ejecución y run para todo lo demás.

Variables de entorno y secretos

Variables de entorno por paso

Cualquier paso puede definir variables de entorno adicionales con el campo env:
- run: pip install -r requirements.txt
  env:
    PIP_INDEX_URL: "https://pypi.example.com/simple/"
    PIP_BREAK_SYSTEM_PACKAGES: "1"
Estas se limitan a este paso y no persisten en los pasos posteriores.

Variables de entorno compartidas entre pasos ($ENVRC)

Para propagar variables de entorno entre pasos, escríbalas en el archivo $ENVRC:
- name: "Set shared variables"
  run: |
    echo "DATABASE_URL=postgresql://localhost:5432/myapp" >> $ENVRC
    echo "APP_ENV=development" >> $ENVRC
Las variables escritas en $ENVRC se exportan automáticamente y están disponibles para todos los pasos siguientes y para la sesión de Devin. Esto funciona de manera similar a $GITHUB_ENV en GitHub Actions.

Secretos

Los secretos configurados en la interfaz de Devin (Settings > Secrets) se inyectan automáticamente como variables de entorno. No hace falta declararlos en tu blueprint. Solo refiérelos por su nombre (p. ej., $MY_SECRET). Los secretos se inyectan antes de ejecutar cada paso durante las compilaciones y se vuelven a inyectar al inicio de cada sesión. Se eliminan de la propia imagen de instantánea, por lo que las credenciales nunca quedan incorporadas en imágenes guardadas de la máquina.
  • Secretos de la organización: Están disponibles como variables de entorno en todos los pasos de todos los blueprints de la org. Configúralos en Settings > Secrets.
  • Secretos de Enterprise: Se combinan con los secretos de la org (los secretos de la org tienen prioridad si hay conflictos de nombre). Están disponibles en todas las orgs de Enterprise.
  • Secretos del repositorio: Se escriben en un archivo por repo en /run/repo_secrets/{owner/repo}/.env.secrets. Durante las compilaciones, los secretos del repo se cargan automáticamente antes de que se ejecuten los pasos del blueprint de ese repo. Durante la sesión, Devin los carga cuando trabaja en el repo. Configúralos en Settings > Secrets con el ámbito de repo.
Secretos solo para compilación: Los secretos marcados como “solo para compilación” están disponibles durante las compilaciones de instantánea, pero se eliminan antes de que se guarde la instantánea. Úsalos para credenciales necesarias solo en tiempo de compilación (p. ej., para descargar artefactos privados durante initialize).
maintenance se ejecuta tanto durante las compilaciones como al inicio de la sesión. Si un paso de maintenance escribe secretos en archivos de configuración (p. ej., ~/.m2/settings.xml, ~/.npmrc), esos archivos quedarán incorporados en la instantánea. Coloca los pasos que escriben credenciales en maintenance (no en initialize) para que se actualicen en cada sesión, pero ten en cuenta que los archivos escritos permanecen en la imagen. Para obtener la máxima seguridad, usa variables de entorno o $ENVRC en lugar de escribir credenciales en disco.

Archivos adjuntos

Puedes subir archivos (como .npmrc, settings.xml y archivos de configuración) desde el editor de blueprints. Los archivos subidos se guardan en ~/.files/ y se configura una variable de entorno que apunta a la ruta de cada archivo:
$FILE_SETTINGS_XML    -> /home/ubuntu/.files/settings.xml
$FILE_NPMRC           -> /home/ubuntu/.files/.npmrc
El nombre de la variable se obtiene a partir del nombre del archivo: en mayúsculas, con los caracteres no alfanuméricos reemplazados por guiones bajos y con el prefijo FILE_. Usa archivos adjuntos en los pasos de tu blueprint:
maintenance:
  - name: "Configure Maven"
    run: |
      mkdir -p ~/.m2
      cp "$FILE_SETTINGS_XML" ~/.m2/settings.xml

Blueprints basados en Git

Actualmente, los blueprints basados en Git no son compatibles. Esta función estará disponible próximamente. Podrás almacenar blueprints en tu repositorio y hacer que las compilaciones se activen automáticamente cuando cambien. Por ahora, configura los blueprints desde la interfaz de usuario en Settings > Configuración de Environment.

Ejemplo completo

Para ver cómo se combinan los blueprints entre niveles (enterprise → org → repo), los estados de compilación, los estados del repositorio y qué activa una recompilación, consulta Compilaciones y sesiones en la página de configuración declarativa.

Blueprint para toda la organización

Herramientas compartidas que necesita cada repo de la organización. Se ejecuta primero (después de cualquier blueprint de Enterprise), en el directorio de inicio.
initialize:
  - name: "Install Node.js 20"
    uses: github.com/actions/setup-node@v4
    with:
      node-version: "20"

  - name: "Install Python 3.12 and uv"
    run: |
      curl -LsSf https://astral.sh/uv/install.sh | sh

  - name: "Install shared tools"
    run: |
      npm install -g pnpm turbo
      apt-get update && apt-get install -y jq ripgrep

  - name: "Configure private registry"
    run: |
      echo "//npm.corp.example.com/:_authToken=$NPM_REGISTRY_TOKEN" >> ~/.npmrc

Blueprint a nivel de repositorio

Configuración específica del proyecto para un monorepo de Node.js y Python. Se ejecuta después del blueprint de toda la organización, en el directorio del repositorio.
initialize:
  - name: "Install Playwright browsers"
    run: npx playwright install --with-deps chromium

  - name: "Set up project environment variables"
    run: |
      echo "DATABASE_URL=postgresql://localhost:5432/myapp_dev" >> $ENVRC
      echo "REDIS_URL=redis://localhost:6379" >> $ENVRC
      echo "APP_ENV=development" >> $ENVRC

maintenance:
  - name: "Install frontend dependencies"
    run: |
      cd frontend
      pnpm install

  - name: "Install backend dependencies"
    run: |
      cd backend
      uv sync

  - name: "Run database migrations"
    run: |
      cd backend
      uv run alembic upgrade head
    env:
      DATABASE_URL: "postgresql://localhost:5432/myapp_dev"

knowledge:
  - name: lint
    contents: |
      Frontend:
      cd frontend && pnpm lint

      Backend:
      cd backend && uv run ruff check .

      Auto-fix:
      cd frontend && pnpm lint --fix
      cd backend && uv run ruff check --fix .

  - name: test
    contents: |
      Frontend unit tests:
      cd frontend && pnpm test

      Backend unit tests:
      cd backend && uv run pytest

      E2E tests (requires dev server running):
      cd frontend && pnpm test:e2e

  - name: build
    contents: |
      Frontend:
      cd frontend && pnpm build

      Backend:
      cd backend && uv run python -m build

  - name: dev-server
    contents: |
      Start the full development stack:
      cd backend && uv run uvicorn main:app --reload &
      cd frontend && pnpm dev

      Frontend: http://localhost:3000
      Backend API: http://localhost:8000
      API docs: http://localhost:8000/docs

  - name: database
    contents: |
      Run migrations:
      cd backend && uv run alembic upgrade head

      Create a new migration:
      cd backend && uv run alembic revision --autogenerate -m "description"

      Reset the database:
      cd backend && uv run alembic downgrade base && uv run alembic upgrade head