Skip to main content
La configuration déclarative (blueprints) est la nouvelle génération de configuration d’environnement : versionnée, composable et mise à jour automatiquement. Ce guide vous explique comment migrer depuis l’assistant interactif classique.

​
Pourquoi migrer ?

Avec l’assistant de configuration classique, l’environnement de Devin est un snapshot configuré manuellement qui peut évoluer au fil du temps. Les dépendances deviennent obsolètes, les modifications de configuration obligent à relancer l’assistant, et il n’y a aucun historique des versions. La configuration déclarative résout ces problèmes :
  • Mises à jour automatiques : les blueprints sont reconstruits lorsque votre repo change, ce qui permet aux dépendances de rester à jour
  • Versionnée : la configuration de votre environnement se trouve à côté de votre code, avec un historique complet
  • Composable : les blueprints Enterprise, org et repo s’empilent proprement
  • Reproductible : chaque build produit le même résultat à partir du même blueprint
  • Sessions plus rapides : les snapshots sont préconstruits, avec les repos clonés et les dépendances installées, afin que les sessions soient prêtes à l’emploi dès leur démarrage
Nous vous recommandons de migrer vers la configuration déclarative lorsque vous serez prêt. Votre configuration classique continue de fonctionner en attendant.

​
Avant de commencer

Cherchez une bannière sur la page Machine Configuration (la page de configuration classique) portant la mention “Passer au nouvel environnement v2 de Devin”. Si elle apparaît, votre organisation est éligible.Si vous ne voyez pas cette bannière, la configuration déclarative n’a pas encore été activée pour votre organisation. Son déploiement se fait progressivement. Contactez l’administrateur de votre entreprise ou le support.
La migration nécessite les autorisations d’administrateur de l’organisation (ManageOrgSettings). Si vous n’êtes pas administrateur de l’organisation, un message « Accès administrateur requis » s’affichera sur la page de migration.
Oui. Votre snapshot actuel est intégralement conservé. Vous pouvez revenir en arrière à tout moment, et votre organisation repassera immédiatement au snapshot précédent. Rien n’est perdu.

​
Étapes de migration

​
1. Accédez à la page de migration

Accédez à Settings > Environment migration, ou cliquez sur Get started sur la bannière affichée sur la page Machine Configuration.

​
2. Activer la configuration déclarative

Cliquez sur Activer pour l’organisation. Cette option fait passer votre organisation à des snapshots basés sur des blueprints pour les nouvelles sessions.
Cela n’affecte pas votre snapshot existant. Il est conservé au cas où vous auriez besoin de revenir en arrière.

​
3. Laissez Devin générer vos blueprints

Devin s’occupe du travail à votre place. Cliquez sur Start migration et sélectionnez les dépôts que vous souhaitez migrer en premier. Vous n’avez pas besoin de tout migrer d’un seul coup. Commencez par vos dépôts les plus utilisés. Lorsque vous démarrez la migration, Devin crée deux sessions :
  • Une session principale exécutée dans le nouvel environnement déclaratif, qui génère les blueprints
  • Une session auxiliaire exécutée à partir de votre snapshot existant, que Devin utilise pour examiner ce qui est actuellement installé (versions des langages, packages système, services en cours d’exécution, etc.)
Devin analyse votre snapshot existant, identifie les outils et dépendances installés, puis génère la configuration de blueprint équivalente. Les résultats s’affichent sur votre page Environment configuration.
Votre snapshot existant est une « boîte noire » de tout ce que vous avez configuré au fil du temps. Devin inspecte ce snapshot, répertorie ce qui est installé et le consigne automatiquement sous la forme d’un blueprint reproductible.

​
4. Passer en revue et ajuster

Une fois les blueprints générés par Devin :
  1. Accédez à Settings > Environment configuration pour passer en revue ce qui a été généré
  2. Vérifiez l’état du build. Assurez-vous qu’il affiche Success.
  3. Démarrez une session de test pour vérifier que tout fonctionne :
    • Vérifiez que les dépôts sont clonés et que les dépendances sont installées
    • Essayez d’exécuter vos commandes de lint, de test et de build
    • Vérifiez que les outils ou runtimes personnalisés sont disponibles
S’il manque quelque chose, modifiez directement le blueprint. Vous pouvez ajouter des étapes initialize, des commandes maintenance ou des entrées knowledge.

​
Retour en arrière

Si quelque chose ne fonctionne pas, revenez en arrière à tout moment :
  1. Accédez à Settings > Environment migration
  2. Cliquez sur Revenir à la configuration classique
  3. Votre organisation revient immédiatement au snapshot précédent
Votre snapshot existant est entièrement préservé. Rien n’est perdu. Vous pourrez retenter la migration dès que vous serez prêt.

​
Correspondance entre les étapes de configuration classiques et les blueprints

Si vous préférez rédiger votre blueprint manuellement (ou comprendre la correspondance), voici comment les étapes de l’assistant classique se traduisent :
Étape classique de configurationÉquivalent dans un blueprintRemarques
Git pullAutomatiqueLes blueprints gèrent automatiquement git clone et git pull
SecretsPanneau Secrets dans l’interfaceÀ configurer dans Settings > Environment configuration
Installer les dépendancesinitializeConfiguration ponctuelle : environnement d’exécution, packages système, outils globaux
Gérer les dépendancesmaintenanceConfiguration récurrente à chaque session : npm install, pip install, etc.
Lintknowledge (name: lint)À titre de référence uniquement, non exécuté lors des builds
Testknowledge (name: test)À titre de référence uniquement, non exécuté lors des builds
Lancer l’applicationknowledge (name: dev-server)À titre de référence uniquement, non exécuté lors des builds
Notes supplémentairesknowledgeEntrées en texte libre pour Devin

​
Exemple

Configuration classique :
  • Installer les dépendances : nvm use 20 && npm install
  • Gérer les dépendances : npm install
  • Lint : npm run lint
  • Tests : npm test
  • Lancer l’application : npm run dev
Blueprint équivalent : 
initialize: |
  curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
  source ~/.bashrc
  nvm install 20

maintenance: |
  npm install

knowledge:
  - name: lint
    contents: npm run lint
  - name: test
    contents: npm test
  - name: dev-server
    contents: npm run dev

​
Dépannage

Consultez les logs de build pour identifier l’erreur précise. Causes courantes :
  • Une commande qui fonctionnait dans le terminal de configuration classique ne fonctionne pas dans le contexte de build (par ex., des invites interactives qui nécessitent des flags -y)
  • Des secrets manquants (assurez-vous que les secrets sont configurés dans le panneau des secrets de l’éditeur de blueprint)
  • Comparez les commandes de votre blueprint à vos commandes d’origine pour repérer les différences
Assurez-vous que votre section maintenance inclut les mêmes commandes d’installation de dépendances que l’étape classique Maintain Dependencies. Les commandes comme npm install ou pip install -r requirements.txt doivent être placées dans maintenance, et non dans initialize.
Vérifiez que votre section knowledge contient des entrées nommées lint et test avec les bonnes commandes. Devin recherche ces noms lorsqu’il vérifie son travail.
Si votre configuration classique modifiait ~/.bashrc, ~/.profile ou un autre fichier de configuration du shell, déplacez ces modifications dans initialize :
initialize: |
  echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
  echo 'export NODE_ENV=development' >> ~/.bashrc
Les blueprints exécutent automatiquement le clonage git pendant les builds. Si les repos ne sont pas clonés, vérifiez qu’ils sont ajoutés à la page Environment configuration et que Devin y a accès via votre intégration Git.