Configurer l’environnement de développement de Devin
Vous n’avez pas besoin d’écrire cela à la main. Le moyen le plus simple de configurer votre environnement est de démarrer une session Devin et de lui demander de configurer le repo. Devin analysera le projet, installera les dépendances et proposera une configuration — vous cliquez sur Approve dans les cartes de suggestion de votre timeline.Ce guide est là si vous voulez comprendre ce que Devin a généré, le personnaliser ou rédiger une configuration à partir de zéro.
Devin s’exécute sur sa propre VM. Chaque session démarre à partir d’une image de machine — un snapshot enregistré dans lequel vos outils, repos et dépendances sont préinstallés. Vous définissez le contenu de cette image en modifiant la configuration de l’environnement dans Settings > Environnement de Devin.
Utilisez initialize pour tout ce qui est long ou ne doit être fait qu’une seule fois : installer des gestionnaires de packages, des outils CLI globaux, compiler des dépendances natives ou ajouter des packages système.Les résultats sont enregistrés dans l’image de machine et ne s’exécutent pas de nouveau au démarrage de la session.
La chaîne sur plusieurs lignes est exécutée comme un script bash unique avec set -e, donc toute ligne qui échoue arrête le build. Utilisez \ pour continuer sur la ligne suivante, ou passez à la forme détaillée pour des étapes nommées qui apparaissent individuellement dans les log de build.
Le fichier secrets est supprimé avant l’enregistrement de l’image de machine. Si une commande dans initialize écrit une donnée sensible dans un fichier de configuration (par ex., un jeton d’authentification dans .npmrc), cette donnée peut persister dans l’image — ce qui présente un risque de sécurité. Placez plutôt les étapes d’écriture des identifiants dans maintenance, où les secrets sont rechargés à chaque session.
Lorsque vous avez besoin de noms d’étape, utilisez la forme en liste. Des étapes nommées rendent les journaux de build plus faciles à déboguer — en cas d’échec, vous verrez quelle étape a échoué plutôt qu’un simple numéro de ligne.
Pour définir des variables d’environnement pour les étapes suivantes, écrivez des lignes KEY=VALUE dans le fichier $ENVRC (comme le $GITHUB_ENV de GitHub Actions). Toutes les variables écrites dans $ENVRC sont automatiquement exportées pour les étapes suivantes et la session Devin.
Utilisez maintenance pour garder les dépendances à jour et écrire les fichiers de configuration des identifiants d’accès.Il s’exécute pendant le build (après initialize) et au début de chaque session, après avoir récupéré la dernière version du code. Puisqu’il s’exécute au début de chaque session, les commandes doivent être rapides et incrémentales.
Utilisez npm install, et non npm ci.npm ci supprime node_modules et réinstalle tout à partir de zéro à chaque exécution. npm install effectue une mise à jour incrémentielle, ce qui est bien plus rapide lorsque les dépendances n’ont pas changé.
Toute étape qui écrit des secrets dans des fichiers de configuration (.npmrc, settings.xml, pip.conf) doit figurer dans maintenance, et non dans initialize. Cela garantit des identifiants à jour au début de chaque session.
knowledge — notes spécifiques à l’environnement (facultatif)
Utilisez knowledge pour de petites informations de configuration dont Devin a besoin pour utiliser réellement l’environnement que vous venez de créer — par exemple la commande de lint, la commande de test ou la façon de démarrer le serveur de développement.
Ce n’est pas la même chose que la fonctionnalité principale Knowledge. Pour la plupart des éléments dont vous voulez que Devin se souvienne — architecture, conventions, points d’attention, workflows d’équipe — utilisez la fonctionnalité Knowledge autonome. Elle dispose de déclencheurs plus riches, est plus facile à modifier et constitue l’emplacement approprié pour le contexte général du projet.Utilisez uniquement la section knowledge dans environment.yaml pour de courtes notes directement liées à la configuration de l’environnement dans ce fichier (p. ex., “la commande de lint est npm run lint”). Cette section est facultative et la plupart des environnements n’en ont pas besoin.
Les entrées sont des notes de référence — elles ne sont pas exécutées. Gardez-les courtes :
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 prend en charge trois niveaux de configuration. Les commandes de chaque niveau sont strictement additives — elles s’exécutent en séquence pendant les builds, et les niveaux inférieurs ne peuvent ni remplacer ni modifier ce que configurent les niveaux supérieurs.
Niveau
Où configurer
Que mettre ici
Exemples
Échelle du compte (Enterprise)
Enterprise Settings > Environment
Infrastructure nécessaire à toutes les orgs
certificats d’autorité de certification, proxy d’entreprise, VPN, DNS
Échelle de l’organisation
Settings > Environment > Organization-wide setup
Outils et configuration partagés entre tous les repos
npm install, commandes de lint/test/build, notes d’architecture
Comment décider de ce qui va où :
Si toutes les orgs de votre Enterprise en ont besoin → à l’échelle du compte
Si tous les repos de votre org en ont besoin → à l’échelle de l’organisation
Si un seul repo en a besoin → spécifique au repo
Utilisateurs Enterprise : Pour obtenir des conseils détaillés sur la configuration au niveau Enterprise — autorisations, cascade des builds, gestion multi-org et migration Enterprise — consultez la page Enterprise Environment Setup.
Votre organisation dispose de une image de machine — un snapshot de VM avec vos outils, repos et dépendances préinstallés. Tous les repos configurés sont clonés et configurés dans cette image unique. Chaque session démarre à partir d’une copie vierge.
Un build crée une nouvelle image de machine dans l’ordre suivant :
1. Configuration Enterprise (s'exécute dans ~) : a. initialize b. maintenance2. Configuration à l'échelle de l'organisation (s'exécute dans ~) : a. initialize b. maintenance3. Cloner tous les dépôts (jusqu'à 10 en simultané)4. Pour chaque dépôt configuré, dans l'ordre affiché dans Settings (s'exécute dans ~/repos/<repo-name>) : a. initialize b. maintenance5. Vérification de l'état, puis l'image est enregistrée
Les couches sont cumulatives : les commandes spécifique au repo peuvent utiliser des outils installés via la configuration à l’échelle de l’organisation ou de l’entreprise. Les niveaux inférieurs ne peuvent pas surcharger ce qui a été défini à un niveau supérieur.Les builds durent généralement de 5 à 15 minutes. Les commandes individuelles expirent au bout d’1 heure ; l’ensemble du build expire au bout de 2 heures.
Chaque session démarre à partir d’une copie vierge de l’image de machine. Lorsque la session se termine, toutes les modifications sont abandonnées.Au démarrage de la session :
Les exécutions maintenance Enterprise et à l’échelle de l’organisation (dans ~) sont lancées.
La dernière version du code est récupérée pour le ou les repos concernés.
La maintenance de ce repo est relancée pour prendre en compte les changements de dépendances depuis le dernier build.
Les entrées knowledge de ce repo sont chargées dans le contexte de Devin.
Knowledge est propre à chaque repo. Si vous avez 5 repos configurés, Devin ne voit que les entrées knowledge de celui sur lequel il travaille.
Toutes les étapes sont terminées. L’image de machine est prête.
Partial
Certains repos ont échoué, mais le build principal a réussi. Les sessions fonctionneront, mais certains repos risquent de ne pas être entièrement configurés.
Failed
Le build principal a échoué (par ex. : échec du clonage, échec de la configuration Enterprise/org).
Cancelled
Remplacé par un build plus récent.
Skipped
Aucune modification de configuration détectée.
Le build échoue ? Consultez Dépannage et FAQ pour obtenir un guide de débogage étape par étape.
Dans l’interface Settings de Environment, les repositories apparaissent dans trois états :
État
Signification
Configuré
Dispose d’une configuration YAML avec initialize/maintenance/knowledge. Entièrement configuré dans l’image de la machine.
Inclus
Cloné dans l’image de la machine, mais sans configuration personnalisée. Devin peut accéder au code.
Disponible
Accessible à l’org, mais non ajouté à l’environnement. Non cloné.
Inclus vs. configuré : Un repo « inclus » est cloné afin que Devin puisse accéder au code, mais il n’a aucune commande de configuration personnalisée. Un repo « configuré » comporte des instructions explicites pour initialize/maintenance/knowledge.
Les secrets sont disponibles sous forme de variables d’environnement pendant les builds et les sessions. Le fichier de secrets est supprimé avant l’enregistrement de l’image de machine — mais si une commande a injecté une valeur de secret dans un fichier de configuration pendant initialize, cette valeur injectée peut persister dans l’image. Écrivez toujours les identifiants dans maintenance à la place, où ils sont rechargés à chaque session.Pour en savoir plus sur la gestion des secrets, consultez Secrets & Site Cookies.
Lorsque vous configurez plusieurs repos, chacun dispose de son propre fichier YAML dans Settings. Lors d’un build, ils sont tous configurés dans la même image — clonés dans des répertoires distincts, avec des dépendances installées séparément. Lors d’une session, seules la maintenance et les Knowledge du repo actif sont pertinentes.Que se passe-t-il si deux repos sont en conflit ? Les commandes de chaque repo s’exécutent dans leur propre répertoire, donc les conflits de dépendances sont rares. Si deux repos installent des versions différentes d’un outil global ou modifient des fichiers partagés (comme ~/.bashrc), le dernier exécuté l’emporte. Placez les installations d’outils partagés dans la configuration à l’échelle de l’organisation pour éviter cela.
Dans le cas d’un monorepo, vous définissez un seul fichier YAML qui couvre l’ensemble des sous-projets. Utilisez des subshells pour exécuter des commandes dans des sous-répertoires sans modifier le répertoire de travail pour les étapes suivantes :
Les parenthèses (cd ... && ...) sont importantes — elles exécutent la commande dans un subshell afin que le répertoire de travail soit réinitialisé à l’étape suivante.Quand utiliser une configuration multi-repo ou monorepo : si le code se trouve dans un seul dépôt Git, utilisez un seul fichier YAML avec des subshells. S’il est réparti sur plusieurs dépôts Git, configurez chaque repo séparément dans Settings.
