Saltar al contenido principal

​
Primeros pasos

Requisitos previos: Devin debe tener acceso a tus repositorios antes de que puedas configurar su entorno. Si todavía no configuraste la integración con Git, consulta Antes de empezar para ver los pasos de configuración. Los usuarios de Enterprise también deben otorgar a cada organización acceso a sus repositorios en Enterprise Settings > Repository Permissions.
¿Sigues usando la configuración clásica? Puedes migrar a la configuración declarativa en cualquier momento. Devin puede encargarse de gran parte de la migración por ti. Consulta Migración a la configuración declarativa.
Lo mejor para la mayoría de los usuarios. Devin analiza tu proyecto, identifica qué herramientas y dependencias hacen falta y genera el blueprint por ti. Tú solo tienes que revisarlo y aprobarlo.
1

Inicia una sesión de Devin

Abre una nueva sesión y pídele a Devin que configure el repositorio. Por ejemplo: “Configura tu entorno para este repositorio.”
2

Revisa y aprueba

Devin propone un blueprint. Verás tarjetas de sugerencias en tu línea de tiempo. Revísalas y haz clic en Approve.
3

Verifica

Cuando finalice la compilación, inicia una nueva sesión. Devin arranca desde la nueva instantánea con todo preconfigurado. Prueba a pedirle a Devin que ejecute tus comandos de lint o de prueba para confirmar que todo funciona.
El resto de esta guía explica en detalle la ruta manual. También es útil para comprender lo que generó Devin si usaste la ruta recomendada.

​
Cómo funciona

La configuración declarativa utiliza tres conceptos:
ConceptoQué esAnalogía
BlueprintUna configuración YAML que describe qué instalar y cómo configurar el entorno de DevinDockerfile
CompilaciónEl proceso que ejecuta tu blueprint, clona repositorios y produce una instantáneadocker build
InstantáneaUna imagen congelada y arrancable del entorno a partir de la cual se inician las sesionesImagen de Docker
Los blueprints describen lo que quieres. Los creas y editas en la interfaz de usuario de Settings. Las compilaciones ejecutan tus blueprints para generar instantáneas. Las compilaciones se ejecutan automáticamente cuando guardas un blueprint y de forma periódica (~cada 24 horas) para mantener las dependencias actualizadas. Las instantáneas son la base desde la que se inician las sesiones. Cada organización tiene una instantánea activa. Cada sesión se inicia desde una copia limpia. Los cambios de la sesión no se conservan en la instantánea.

​
Secciones del blueprint

Un blueprint tiene tres secciones:
SectionPurposeWhen it runs
initializeInstala herramientas, entornos de ejecución y paquetes del sistemaSolo durante las compilaciones. Los resultados se guardan en la instantánea.
maintenanceInstala o actualiza las dependencias del proyecto y escribe configuraciones de credencialesDurante las compilaciones y al inicio de cada sesión
knowledgeInformación de referencia para Devin (comandos de lint, test y compilación)No se ejecuta. Se carga en el contexto de Devin al inicio de la sesión.
initialize es para tareas que solo deben realizarse una vez: entornos de ejecución de lenguajes, paquetes del sistema y herramientas CLI globales. maintenance es para la instalación de dependencias que deben mantenerse actualizadas. Se ejecuta durante las compilaciones y de nuevo al inicio de la sesión después de extraer el código más reciente, por lo que los comandos deben ser rápidos e incrementales (usa npm install, no npm ci). knowledge es información de referencia; no se ejecuta. Así es como le indicas a Devin los comandos correctos para linting, testing y compilación. Mantén las entradas ligeras y centradas en comandos ejecutables.
Knowledge aquí frente a la función de producto Knowledge: La sección knowledge de tu blueprint es para referencias breves de comandos vinculadas al entorno. Para documentación de arquitectura, convenciones y flujos de trabajo del equipo, usa en su lugar la función independiente Knowledge.
Para ver la especificación completa de los campos (tipos de pasos, compatibilidad con GitHub Actions, variables de entorno, secretos y archivos adjuntos), consulta la referencia de Blueprint.

​
Ámbito del blueprint

Puedes definir blueprints en dos niveles:
NivelDónde configurarloQué incluir aquí
OrganizaciónSettings > Configuración de Environment > configuración de toda la organizaciónHerramientas compartidas en todos los repositorios: entornos de ejecución, gestores de paquetes, autenticación de Docker
RepositorioSettings > Configuración de Environment > [nombre del repo]Configuración específica del proyecto: npm install, comandos de lint/test/build
Los blueprints son acumulativos: los blueprints de los repositorios se añaden sobre el blueprint de la organización. El maintenance de un repositorio puede usar herramientas instaladas por el initialize de la organización. Si solo un repositorio necesita una herramienta, colócala en el blueprint de ese repositorio. Si todos los repositorios la necesitan, colócala en el blueprint de la organización.
Usuarios de Enterprise: Hay un tercer nivel, el blueprint de Enterprise, que se aplica a todas las organizaciones. Consulta la descripción general del entorno de Enterprise para obtener más información.

​
Compilaciones y sesiones

​
La instantánea

Tu organización tiene una instantánea activa: una imagen de máquina virtual con tus herramientas, repositorios y dependencias preinstalados. Todos los repositorios configurados se clonan y se preparan en esa única imagen. Cada sesión se inicia a partir de una copia limpia.

​
Cómo funcionan las compilaciones

Una compilación crea una nueva instantánea ejecutando tus blueprints en secuencia: 
1. Enterprise blueprint, if configured (runs in ~):
   a. initialize
   b. maintenance
2. Org blueprint (runs in ~):
   a. initialize
   b. maintenance
3. Clone all repositories (up to 10 concurrent)
4. For each configured repo, in the order shown in Settings
   (runs in ~/repos/<repo-name>):
   a. initialize
   b. maintenance
5. Health check, then snapshot is saved
Las capas son acumulativas: los comandos específicos del repo pueden usar herramientas instaladas por la org o el blueprint de Enterprise. Los niveles inferiores no pueden anular lo que configuró un nivel superior. Las compilaciones suelen tardar entre 5 y 15 minutos. Los pasos individuales tienen un tiempo de espera de 1 hora.

​
Cómo funcionan las sesiones

Cada sesión arranca con una copia limpia de la instantánea. Cuando la sesión termina, se descartan todos los cambios. Al inicio de la sesión:
  1. Se ejecuta maintenance de Enterprise y de toda la organización (en ~).
  2. Se descarga el código más reciente de los repositorios relevantes.
  3. Se vuelve a ejecutar maintenance de ese repo para detectar cambios en las dependencias desde la última compilación.
  4. Las entradas de knowledge de ese repo se cargan en el contexto de Devin.
Knowledge es específico de cada repo. Si tienes 5 repos configurados, Devin solo ve las entradas de Knowledge del repo en el que está trabajando.

​
Qué activa una compilación

EventoDescripción
Guardar un blueprintCrear, actualizar o eliminar un blueprint
Agregar o quitar un repositorioCualquier cambio en la lista de repositorios
Agregar un secreto de repositorioLos secretos nuevos requieren una nueva compilación para estar disponibles
Activación manualHacer clic en Build o Rebuild en la UI
Actualización periódicaAutomática, aproximadamente cada 24 horas
Sugerencia de DevinDevin propone un cambio en el blueprint durante una sesión
Solo se ejecuta una compilación a la vez. Los eventos nuevos cancelan cualquier compilación en cola y la reinician desde cero.

​
Estados de compilación

EstadoSignificado
ÉxitoTodos los pasos se completaron. La instantánea está lista.
ParcialAlgunos pasos a nivel de repo fallaron, pero la instantánea se puede usar. Los repos que se completaron correctamente funcionan con normalidad; los repos que fallaron requieren corregir sus blueprints.
FallidaError crítico (falló la configuración de la org o de Enterprise). La instantánea no se puede usar.
CanceladaFue reemplazada por una compilación más reciente o se canceló manualmente.
Una compilación parcial sigue generando una instantánea funcional. Si uno de cinco repos tiene un blueprint dañado, los otros cuatro son completamente funcionales.
¿Está fallando la compilación? Consulta Solución de problemas de compilaciones para obtener una guía de depuración paso a paso.

​
Administrar tu Environment

​
Estados de los repositorios

Los repositorios aparecen en tres estados en los Settings de Environment:
EstadoSignificado
ConfiguradoTiene un blueprint con initialize/maintenance/knowledge. Está completamente configurado en la instantánea.
IncluidoEstá clonado en la instantánea, pero no tiene un blueprint personalizado. Devin puede acceder al código.
DisponibleEstá conectado a la organización, pero no se agregó al entorno. No está clonado.
Incluido vs. configurado: Un repositorio “incluido” está clonado para que Devin pueda acceder al código, pero no tiene comandos de configuración personalizados. Un repositorio “configurado” tiene instrucciones explícitas de initialize/maintenance/knowledge.

​
Secrets

Usa la sintaxis $VARIABLE_NAME para hacer referencia a los secrets. Agrégalos en Settings > Secrets. 
maintenance:
  - name: Configure private registry
    run: npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
Los secretos están disponibles como variables de entorno durante las compilaciones y las sesiones. Se eliminan antes de guardar la instantánea, pero si un comando escribe un valor secreto en un archivo de configuración durante initialize, ese valor permanece en la instantánea. Escriba siempre las credenciales en maintenance. Para obtener más información sobre los ámbitos de los secretos y su comportamiento, consulte la referencia de Blueprint.

​
Múltiples repositorios

Cada repo tiene su propio blueprint. Durante una compilación, todos los repos se configuran en la misma instantánea, se clonan en directorios separados y sus dependencias se instalan de forma independiente. Si dos repos instalan versiones diferentes de una herramienta global o modifican archivos compartidos (como ~/.bashrc), prevalece el último que se ejecuta. Para evitar conflictos, coloca las instalaciones de herramientas compartidas en el blueprint de toda la organización.

​
Monorepos

En un monorepo, escribe un único blueprint que abarque todos los subproyectos. Usa subshells para ejecutar comandos en subdirectorios: 
maintenance:
  - name: Frontend deps
    run: (cd packages/frontend && pnpm install)
  - name: Backend deps
    run: (cd packages/backend && uv sync)
Los paréntesis (cd ... && ...) se ejecutan en una subshell, por lo que el directorio de trabajo se restablece para el siguiente paso.

​
Anclaje y actualizaciones automáticas

De forma predeterminada, Devin usa la instantánea de la compilación correcta más reciente. Anclar te permite fijar la instantánea de una compilación específica. Esto es útil cuando una compilación nueva introduce una regresión o cuando quieres congelar el entorno para un conjunto de sesiones. Para anclar: Ve a Snapshot build history, busca la compilación (debe ser success o partial y tener menos de 7 días de antigüedad) y haz clic en Pin. Mientras esté anclada, se omiten las actualizaciones periódicas y la interfaz muestra Auto-updates paused. Para desanclar: Haz clic en Resume auto-updates. Devin cambia a la compilación correcta más reciente.

​
Blueprints basados en Git

Los blueprints basados en Git aún no son compatibles. Esta función estará disponible pronto. Podrás almacenar blueprints en tu repositorio y hacer que las compilaciones se inicien automáticamente cuando cambien. Por ahora, configura los blueprints desde la interfaz de usuario.

​
Solución de problemas de compilación

​
Falló el paso initialize

Causas comunes: error tipográfico en un comando de shell, paquete no disponible, tiempo de espera de red agotado, referencia incorrecta de GitHub Action. Solución: Revisa los registros de compilación para ver el error exacto. Actualiza initialize en tu blueprint y guarda. Esto activa automáticamente una nueva compilación.

​
Falló la clonación del repositorio

Causas comunes: Devin no tiene acceso al repositorio, se cambió el nombre del repositorio/se movió/se eliminó, o hay un problema de red transitorio. Solución: Verifica el acceso al repositorio en la configuración de tu proveedor de Git. Elimina el repositorio y vuelve a agregarlo si se cambió de nombre.

​
Falló el paso de mantenimiento

Causas comunes: conflicto de dependencias, falta de una biblioteca del sistema, falta de espacio en disco, archivo de bloqueo fuera de sincronización. Solución: Revisa los logs del paquete o comando que falló. Actualiza maintenance o initialize para instalar las dependencias que faltan, o corrige el archivo de bloqueo en tu repositorio.

​
Tiempo de espera de compilación

Cada paso tiene un tiempo límite de 1 hora. Algunas causas comunes: compilar grandes dependencias nativas desde el código fuente (use binarios precompilados), descargar artefactos grandes y comandos que quedan bloqueados esperando entrada (todos los comandos deben ejecutarse de forma no interactiva).

​
Iteración de correcciones

  1. Revisa los logs de compilación para identificar el fallo
  2. Actualiza el blueprint correspondiente
  3. Guarda (una nueva compilación se activa automáticamente)
  4. Supervisa los logs de la nueva compilación
  5. Repite hasta que la compilación finalice correctamente
No necesitas esperar a que termine una compilación fallida. Guardar una nueva configuración cancela cualquier compilación en cola y vuelve a empezar desde cero.

​
Siguientes pasos

Referencia de blueprints

Referencia completa de campos: tipos de pasos, GitHub Actions, variables de entorno, secretos y archivos adjuntos.

Biblioteca de plantillas

Blueprints listos para copiar y pegar para Python, Node.js, Go, Java, Ruby, Rust y patrones avanzados.

Migración desde la configuración clásica

Guía paso a paso para pasar del asistente interactivo a los blueprints declarativos.

Gestión de entornos Enterprise

Gestión de entornos a nivel Enterprise: jerarquía de 3 niveles, secretos y configuración entre organizaciones.