En règle générale : les blueprints de dépôt installent les dépendances du projet, les blueprints d’organisation installent tout ce qui est partagé par plusieurs dépôts, et les blueprints d’entreprise installent tout ce dont chaque organisation a besoin. Les niveaux sont additifs et s’exécutent de haut en bas : entreprise → organisation → cloner les dépôts → dépôt.
Étape 1 : un dépôt
acme-web, une application Rails avec Postgres et Redis. Deux ingénieurs, un seul dépôt. Il n’y a encore rien à mutualiser, donc tout va dans le blueprint du dépôt.
Ils ajoutent le dépôt dans Settings > Environment > Blueprints > Add, ouvrent son éditeur et écrivent :
acme-web (repository blueprint)
Deux ans plus tard, ACME a cinq dépôts :
C’est là que les choses deviennent intéressantes, car les dépôts ne sont pas indépendants : on ne peut rien faire d’utile dans
acme-portal tant que acme-devtools n’est pas installé et que acme-sso n’est pas en cours d’exécution. Deux questions se posent.
”Un blueprint par application, ou un seul pour la CLI de développement ?”
- Ajoutez les cinq dépôts à l’environnement pour qu’ils soient tous clonés dans le snapshot.
- Placez la configuration partagée entre plusieurs dépôts, une seule fois, dans le blueprint d’organisation : environnements d’exécution, Docker, noms d’hôte locaux et identifiants du registre interne.
- Donnez à chaque dépôt son propre blueprint de dépôt pour ses dépendances propres et ses entrées
knowledgespécifiques (commandes de lint, de test et de démarrage).
acme-devtools : les blueprints de dépôt s’exécutent une fois que tous les dépôts ont été clonés, mais leurs étapes s’exécutent dans le répertoire du dépôt concerné, et leurs entrées knowledge ne sont chargées que lorsque Devin travaille dans ce dépôt. Si acme-devtools installait tout, une session travaillant dans acme-portal ne verrait aucune des commandes de lint et de test du portail, et une seule étape acme-devtools en échec laisserait les quatre autres dépôts en apparence sains, mais inutilisables.
Le blueprint d’organisation
Organization-wide setup
-
initializeversusmaintenance. Docker, les environnements d’exécution et les noms d’hôte relèvent d’une configuration système ponctuelle ; ils doivent donc aller dansinitialize. Les identifiants du registre doivent être actualisés à chaque build périodique ; ils doivent donc aller dansmaintenance. Le CLIacmelui-même est volontairement absent ici. Il se trouve dansacme-devtools, et les étapes au niveau de l’organisation s’exécutent avant le clonage de tout dépôt ; il est donc installé depuis le blueprint propre à ce dépôt (présenté ci-dessous). Cette installation s’exécute pendant le build et est conservée dans le snapshot, que tous les autres dépôts peuvent ensuite utiliser. -
post-buildest le véritable avantage des configurations multi-dépôts. Il s’exécute une fois que tous les dépôts ont été clonés et configurés ; c’est donc le seul endroit où vous pouvez vérifier que toute la stack démarre correctement ensemble. Un code de sortie non nul fait échouer le build, ce qui vous permet de repérer une stack défaillante au moment du build plutôt qu’en pleine session. Voirpost-build. -
Les secrets relèvent de l’organisation, et non de chaque dépôt. Un seul
ACME_REGISTRY_TOKENdans l’onglet Secrets du blueprint d’organisation suffit pour les commandesbundle installetnpm installde tous les dépôts.
Les blueprints de dépôt
acme-devtools (repository blueprint)
acme-portal (repository blueprint)
acme-web, acme-sso et acme-events ont la même structure : une étape maintenance pour leurs propres dépendances, et des entrées knowledge pour leurs propres commandes de lint, de test et de démarrage.
Knowledge est propre à chaque dépôt. Avec cinq dépôts configurés, une session qui travaille dans
acme-portal voit les entrées Knowledge du portail, ainsi que celles de l’organisation et de l’entreprise, mais pas celles de acme-web. C’est pourquoi chaque dépôt mérite son propre blueprint, même lorsque sa section maintenance ne fait qu’une ligne.Si vos services se trouvent plutôt dans un monorepo
Étape 3 : plusieurs organisations — le blueprint d’entreprise
- Tout le trafic passe par un proxy d’entreprise, avec une autorité de certification interne.
- Tous les packages proviennent d’Artifactory, jamais de dépôts publics.
- Chaque environnement doit disposer des outils de détection des dépendances et des secrets de l’entreprise.
- Python est en version 3.12 et Node.js en version 20 dans toute l’entreprise, sans exception.
Devin's base environment (enterprise blueprint)
ARTIFACTORY_TOKEN est un secret d’entreprise, défini une seule fois dans Settings > environnement de base de Devin > Secrets et disponible dans chaque build et chaque session de chaque organisation. Le certificat est un fichier joint, mis à disposition du build sous la forme de $FILE_ACME_CA_CERT.
Ce que gère désormais chaque niveau
Le blueprint d’organisation Payments de l’étape 2 continue de fonctionner sans changement. Il n’a simplement plus besoin d’installer Python ni de configurer les registres, car le niveau Entreprise l’a déjà fait. Le blueprint d’organisation Data installe Spark et un JDK, que Payments n’utilise jamais. Les blueprints de dépôt restent inchangés.
L’utiliser
- La mise à niveau de Python de 3.12 vers 3.13 se résume à modifier une seule ligne, puis à lancer un rebuild à l’échelle de l’entreprise, qui se propage à toutes les organisations.
- Lorsqu’une Team a besoin d’un identifiant différent — par exemple, si l’organisation Data dispose de son propre realm Artifactory — cette Team définit un secret d’organisation portant le même nom, et il prévaut sur le secret d’entreprise.
- Pour déployer cela progressivement dans les organisations, consultez Migrer votre entreprise.
Déterminer où placer chaque élément
1
Est-ce que toutes les organisations de l’entreprise en ont besoin ?
→ Blueprint d’entreprise. Certificats, proxys, registres internes, environnements d’exécution imposés, outils de sécurité et secrets à l’échelle de l’entreprise.
2
Est-ce que deux dépôts ou plus dans cette organisation en ont besoin ?
→ Blueprint d’organisation. Docker, CLI de développement partagés, noms d’hôte locaux, orchestration de services entre dépôts et identifiants de registre. Validez la pile obtenue dans
post-build.3
Est-ce que seul ce dépôt en a besoin ?
→ Blueprint de dépôt. Installation des dépendances, migrations et entrées
knowledge pour ses commandes de lint, de test et de démarrage.4
S’agit-il d’une information plutôt que d’une commande à exécuter ?
→
knowledge, au niveau concerné. Il n’est jamais exécuté ; il est chargé dans le contexte de Devin.- Tout mettre dans le blueprint d’un seul dépôt. Les autres dépôts n’obtiennent aucune entrée
knowledge, et une seule étape défaillante peut donner l’impression que toute la configuration est en mauvais état. - Dupliquer les outils partagés dans chaque dépôt. Quand deux dépôts installent des versions différentes du même outil global, c’est la dernière exécution qui l’emporte. Placez plutôt l’outil dans le blueprint d’organisation.
- Ignorer la vérification entre dépôts. Quand vos dépôts ne fonctionnent qu’ensemble,
post-buildest le seul endroit où vous pouvez le vérifier — avant le début d’une session, plutôt qu’en cours de session.
- Configuration déclarative — ordre de build, snapshots et dépannage
- référence Blueprint — tous les champs, y compris
post-buildetclone - bibliothèque de modèles — blueprints à copier-coller par langage et par registre
- Workspaces and monorepos — l’équivalent monorepo de l’étape 2
- Vue d’ensemble de l’environnement Enterprise — l’étape 3 en détail

