No necesitas escribir esto a mano. La forma más sencilla de configurar tu Environment es iniciar una sesión de Devin y pedirle que configure el repositorio. Devin analizará el proyecto, instalará dependencias y propondrá una configuración — haces clic en Approve en las tarjetas de sugerencias de tu cronología.Esta guía es para cuando quieras comprender lo que Devin generó, personalizarlo o escribir una configuración desde cero.
Devin se ejecuta en su propia VM. Cada sesión arranca a partir de una imagen de la máquina: una instantánea guardada con tus herramientas, repositorios y dependencias ya preinstalados. Controlas lo que se incluye en esa imagen editando la configuración del Environment en Settings > Environment de Devin.
Usa initialize para cualquier proceso lento o que solo deba ocurrir una vez: instalar gestores de paquetes, herramientas CLI globales, compilar dependencias nativas o agregar paquetes del sistema.Los resultados se guardan en la imagen de la máquina y no se vuelven a ejecutar al inicio de la sesión.
La cadena de varias líneas se ejecuta como un único script de bash con set -e, por lo que cualquier línea que falle detiene la compilación. Usa \ para continuar la línea o cambia a la forma expandida con pasos con nombre que se muestren individualmente en los registros de compilación.
El archivo de secrets se elimina antes de guardar la imagen de la máquina. Si un comando en initialize escribe un valor secreto en un archivo de configuración (p. ej., un token de autenticación en .npmrc), ese valor puede persistir en la imagen, lo que supone un riesgo de seguridad. En su lugar, coloca los pasos que escriben credenciales en maintenance, donde los secrets se vuelven a cargar en cada sesión.
Cuando necesites nombres para cada paso, usa la forma de lista. Los pasos con nombre facilitan la depuración de los registros de compilación: cuando algo falla, verás qué paso falló en lugar de solo un número de línea.
Para definir variables de entorno para los pasos siguientes, escribe líneas KEY=VALUE en el archivo $ENVRC (como $GITHUB_ENV de GitHub Actions). Todas las variables escritas en $ENVRC se exportan automáticamente para los pasos siguientes y la sesión de Devin.
Usa maintenance para mantener las dependencias actualizadas y escribir archivos de configuración de credenciales.Se ejecuta durante la compilación (después de initialize) y al inicio de cada sesión, después de actualizar el código con los cambios más recientes. Como se ejecuta al inicio de cada sesión, los comandos deben ser rápidos e incrementales.
Usa npm install, no npm ci.npm ci elimina node_modules y reinstala todo desde cero en cada ejecución. npm install hace una actualización incremental, que es mucho más rápida cuando las dependencias no han cambiado.
Cualquier paso que escriba secretos en archivos de configuración (.npmrc, settings.xml, pip.conf) debe ir en maintenance, no en initialize. Esto mantiene las credenciales actualizadas al inicio de cada sesión.
knowledge — notas específicas del entorno (opcional)
Usa knowledge para pequeños fragmentos de información de configuración que Devin necesita para usar realmente el entorno que acabas de crear: cosas como el comando de lint, el comando de prueba o cómo iniciar el servidor de desarrollo.
Esto no es lo mismo que la función principal Knowledge. Para la mayoría de las cosas que quieres que Devin recuerde — arquitectura, convenciones, aspectos a tener en cuenta, flujos de trabajo del equipo — usa la función independiente Knowledge. Tiene activadores más completos, es más fácil de editar y es el lugar adecuado para el contexto general del proyecto.Usa la sección knowledge en environment.yaml solo para notas breves que estén directamente vinculadas a la configuración del entorno en este archivo (p. ej., “el comando de lint es npm run lint”). Esta sección es opcional y la mayoría de los entornos no la necesitan.
Las entradas son notas de referencia: no se ejecutan. Mantenlas breves:
knowledge: - name: lint contents: | Run `npm run lint` to check for errors. Run `npm run lint:fix` to auto-fix. - name: test contents: | Run `npm test` for the full suite. Run `npm test -- --watch` during development. - name: startup contents: | Run `npm run dev` to start the dev server on port 3000.
Devin admite tres niveles de configuración. Los comandos de cada nivel son estrictamente aditivos: se ejecutan en secuencia durante las compilaciones, y los niveles inferiores no pueden sobrescribir ni modificar lo que configuran los niveles superiores.
Nivel
Dónde configurar
Qué poner aquí
Ejemplos
Cuenta (Enterprise)
Enterprise Settings > Environment
Infraestructura que necesitan todas las organizaciones
Certificados de CA, proxy corporativo, VPN, DNS
Organización
Settings > Environment > Organization-wide setup
Herramientas y configuración compartidas entre todos los repositorios
Entornos de ejecución (pnpm, uv), autenticación de Docker, herramientas de CLI compartidas
Específico del repositorio
Settings > Environment > [repo]
Configuración específica del proyecto
npm install, comandos de lint/test/compilación, notas de arquitectura
Cómo decidir qué va en cada nivel:
Si todas las organizaciones de tu Enterprise lo necesitan → cuenta
Si todos los repositorios de tu organización lo necesitan → organización
Si solo lo necesita un repositorio → específico del repositorio
Usuarios de Enterprise: Para obtener instrucciones detalladas sobre la configuración a nivel Enterprise — permisos, compilaciones en cascada, gestión de múltiples organizaciones y migración a Enterprise — consulta la página Enterprise Environment Setup.
Tu organización tiene una imagen de la máquina: una instantánea de una VM con tus herramientas, repositorios y dependencias preinstalados. Todos los repositorios configurados se clonan y se configuran en esa única imagen. Cada sesión se inicia a partir de una copia limpia.
Una compilación crea una nueva imagen de la máquina en este orden:
1. Configuración Enterprise (se ejecuta en ~): a. initialize b. maintenance2. Configuración de organización (se ejecuta en ~): a. initialize b. maintenance3. Clonar todos los repositorios (hasta 10 simultáneos)4. Para cada repositorio configurado, en el orden mostrado en Settings (se ejecuta en ~/repos/<repo-name>): a. initialize b. maintenance5. Verificación de estado, luego se guarda la imagen
Las capas son aditivas: los comandos específicos del repositorio pueden usar herramientas instaladas por la configuración de toda la organización o de Enterprise. Los niveles inferiores no pueden anular lo que configuró un nivel superior.Las compilaciones suelen tardar entre 5 y 15 minutos. Los comandos individuales tienen un tiempo de espera de 1 hora; la compilación completa tiene un tiempo de espera de 2 horas.
Cada sesión arranca con una copia limpia de la imagen de la máquina. Cuando la sesión termina, todos los cambios se descartan.Al inicio de la sesión:
Se ejecuta maintenance de Enterprise y de toda la organización (en ~).
Se obtiene el código más reciente del/de los repositorios correspondientes.
maintenance de ese repositorio se ejecuta de nuevo para detectar cambios en las dependencias desde la última compilación.
Las entradas de knowledge de ese repositorio se cargan en el contexto de Devin.
La información es por repositorio. Si tienes 5 repositorios configurados, Devin solo ve las entradas de información del repositorio en el que está trabajando.
Se completaron todos los pasos. La imagen de la máquina está lista.
Partial
Algunos repos fallaron, pero la compilación principal se completó correctamente. Las sesiones funcionarán, pero es posible que algunos repos no queden totalmente configurados.
Failed
La compilación principal falló (p. ej., falló la clonación o la configuración de Enterprise/org).
Cancelled
Fue reemplazada por una compilación más reciente.
Skipped
No se detectaron cambios en la configuración.
¿Está fallando la compilación? Consulta Troubleshooting & FAQ para ver una guía de depuración paso a paso.
En la interfaz de usuario de Environment Settings, los repositorios aparecen en tres estados:
Estado
Significado
Configured
Tiene configuración YAML con initialize/maintenance. Está totalmente configurado en la imagen de la máquina.
Included
Está clonado en la imagen de la máquina, pero no tiene configuración personalizada. Devin puede acceder al código.
Available
Es accesible para la org, pero no se ha agregado al Environment. No está clonado.
Included vs. Configured: Un repositorio “included” está clonado para que Devin pueda acceder al código, pero no tiene comandos de configuración personalizados. Un repositorio “configured” tiene instrucciones explícitas de initialize/maintenance.
Los secretos están disponibles como variables de Environment durante las compilaciones y las sesiones. El archivo de secretos se elimina antes de que se guarde la imagen de la máquina, pero si un comando expandió un valor secreto en un archivo de configuración durante initialize, ese valor expandido puede persistir en la imagen. En su lugar, escribe siempre las credenciales en maintenance, donde se vuelven a cargar en cada sesión.Para obtener más información sobre la gestión de secretos, consulta Secrets & Site Cookies.
Cuando configuras varios repositorios, cada uno tiene su propio YAML en Settings. Durante una compilación, todos se configuran en la misma imagen: se clonan en directorios separados y las dependencias se instalan de forma independiente. Durante una sesión, solo son relevantes el mantenimiento y la información del repositorio activo.¿Qué pasa si dos repositorios entran en conflicto? Los comandos de cada repositorio se ejecutan en su propio directorio, por lo que los conflictos de dependencias son poco frecuentes. Si dos repositorios instalan versiones diferentes de una herramienta global o modifican archivos compartidos (como ~/.bashrc), prevalece el último que se ejecute. Coloca las instalaciones de herramientas compartidas en la configuración de la organización para evitarlo.
En un monorepo, escribe un único archivo YAML que abarque todos los subproyectos. Usa subshells para ejecutar comandos en subdirectorios sin cambiar el directorio de trabajo en los pasos posteriores:
Los paréntesis (cd ... && ...) son importantes: ejecutan el comando en una subshell para que el directorio de trabajo se restablezca en el siguiente paso.Cuándo usar configuración multi-repositorio vs. monorepo: Si el código está en un solo repositorio de Git, usa un único YAML con subshells. Si está distribuido en varios repositorios de Git, configura cada repositorio por separado en Settings.
