Skip to main content
Les blueprints comportent trois niveaux — dépôt, organisation et entreprise — et la question la plus fréquente est : dans quel niveau faut-il placer cela ? Cette page répond à cette question en suivant une entreprise fictive, ACME Corp, au fil de trois étapes de croissance. Chaque étape introduit exactement un nouveau problème, et chaque problème est résolu par le niveau immédiatement supérieur. Passez directement à l’étape qui ressemble le plus à votre entreprise.
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 a un produit : 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)
C’est toute la configuration. Ils l’enregistrent, un build se lance, et chaque session démarre avec Ruby installé, Postgres lancé, les gems installées et la base de données migrée. Pourquoi pas encore de blueprint d’organisation ? Un blueprint d’organisation qui ne sert qu’à un seul dépôt n’est qu’un niveau d’indirection. Attendez qu’un deuxième dépôt en ait besoin.
ACME n’a pas écrit cela à la main. Ils ont demandé à Devin “configure ton environnement pour ce dépôt”, ont examiné la carte de suggestion, puis ont cliqué sur Approve. Consultez Prise en main.

Étape 2 : plusieurs dépôts avec des dépendances partagées

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 ?”

Les deux — ils n’ont pas le même rôle. Devin construit un snapshot contenant tous les dépôts configurés : ce n’est donc pas un choix à faire entre l’un ou l’autre.
  • 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 knowledge spécifiques (commandes de lint, de test et de démarrage).
Voici pourquoi il ne faut pas tout regrouper dans le blueprint 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
Trois points à noter :
  1. initialize versus maintenance. Docker, les environnements d’exécution et les noms d’hôte relèvent d’une configuration système ponctuelle ; ils doivent donc aller dans initialize. Les identifiants du registre doivent être actualisés à chaque build périodique ; ils doivent donc aller dans maintenance. Le CLI acme lui-même est volontairement absent ici. Il se trouve dans acme-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.
  2. post-build est 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. Voir post-build.
  3. Les secrets relèvent de l’organisation, et non de chaque dépôt. Un seul ACME_REGISTRY_TOKEN dans l’onglet Secrets du blueprint d’organisation suffit pour les commandes bundle install et npm install de tous les dépôts.
Point d’attention sur l’ordre d’exécution : initialize et maintenance au niveau de l’organisation s’exécutent tous deux avant le clonage des dépôts (voir l’ordre du build). Tout ce qui nécessite du code source déjà extrait — comme un CLI présent dans l’un de vos dépôts — doit aller dans le blueprint de ce dépôt ou dans post-build, pas dans maintenance au niveau de l’organisation. Ne le laissez au niveau de l’organisation que si vous pouvez l’installer depuis un artefact publié, comme une archive tar, un package ou une image de conteneur.

Les blueprints de dépôt

Chaque blueprint de dépôt reste succinct, puisque tout ce qui est partagé existe déjà :
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.
Placez acme-devtools en premier dans la liste des dépôts. Les blueprints de dépôt s’exécutent dans l’ordre affiché dans Settings ; le dépôt qui fournit la CLI partagée doit donc être configuré avant les dépôts qui l’utilisent.
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.
Comme la CLI acme sait déjà tout exécuter, la partie la plus utile de ces blueprints est la section knowledge : elle indique à Devin quelle commande CLI utiliser. Faites-la pointer vers votre moteur de recherche interne dans la documentation, si vous en avez un.

Si vos services se trouvent plutôt dans un monorepo

L’idée est la même, mais à un niveau inférieur : utilisez des espaces de travail pour donner à chaque package sa propre configuration et son propre Knowledge dans un seul dépôt, au lieu d’un blueprint par dépôt.

Étape 3 : plusieurs organisations — le blueprint d’entreprise

ACME compte désormais 400 ingénieurs. Platform, Payments et Data ont chacun leur propre organisation Devin, avec des dépôts distincts, des membres distincts et des snapshots distincts. Une équipe de sécurité a des exigences qui s’appliquent à toutes :
  • 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.
Rien de tout cela n’a sa place dans un blueprint d’organisation, car il faudrait le copier dans chaque organisation, et il finirait par diverger dès qu’une équipe oublierait de le mettre à jour. C’est à cela que sert le blueprint d’entreprise : un environnement de base qui s’exécute en premier, dans le build de chaque organisation, à l’échelle de toute l’entreprise.
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

Parcourez la liste dans l’ordre. Le premier « oui » vous donne la réponse :
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.
Erreurs courantes que cela permet d’éviter :
  • 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-build est le seul endroit où vous pouvez le vérifier — avant le début d’une session, plutôt qu’en cours de session.