Die Faustregel vorweg: Repository-Blueprints installieren Projektabhängigkeiten, Organisations-Blueprints installieren alles, was von mehr als einem Repository gemeinsam genutzt wird, und Enterprise-Blueprints installieren alles, was jede Organisation haben muss. Die Ebenen sind additiv und werden von oben nach unten angewendet: Enterprise → Organisation → Repositories klonen → Repository.
Phase 1: ein Repository
acme-web, eine Rails-Anwendung mit Postgres und Redis. Zwei Entwickler, ein Repository. Es gibt noch nichts zu teilen, daher landet alles im Repository-Blueprint.
Sie fügen das Repository unter Settings > Environment > Blueprints > Add hinzu, öffnen den zugehörigen Editor und schreiben:
acme-web (repository blueprint)
Zwei Jahre später hat ACME fünf Repositories:
Das ist der interessante Fall, weil die Repositories nicht unabhängig sind: In
acme-portal lässt sich nichts Sinnvolles tun, solange acme-devtools nicht installiert ist und acme-sso nicht läuft. Daraus ergeben sich zwei Fragen.
„Ein Blueprint pro Anwendung oder nur einer für die Entwicklungs-CLI?“
- Fügen Sie alle fünf Repositories zur Umgebung hinzu, damit sie alle in den Snapshot geklont werden.
- Hinterlegen Sie das gemeinsame, repository-übergreifende Setup einmalig im Organisations-Blueprint: Sprachruntimes, Docker, lokale Hostnames und Zugangsdaten für die interne Registry.
- Geben Sie jedem Repository sein eigenes Repository-Blueprint für seine eigenen Abhängigkeiten und seine eigenen
knowledge-Einträge (Lint-, Test- und Startbefehle).
acme-devtools-Blueprint bündeln: Repository-Blueprints werden ausgeführt, nachdem alle Repositories geklont wurden, aber ihre Schritte laufen im Verzeichnis des jeweiligen Repositorys, und ihre knowledge-Einträge werden nur geladen, wenn Devin in diesem Repository arbeitet. Wenn acme-devtools alles installieren würde, sähe eine Sitzung, die in acme-portal arbeitet, keine der Lint- und Testbefehle des Portals, und ein einzelner fehlgeschlagener Schritt in acme-devtools würde die anderen vier Repositories zwar gesund erscheinen lassen, sie aber unbrauchbar machen.
Das Organisations-Blueprint
Organization-wide setup
-
initializeversusmaintenance. Docker, Runtimes und Hostnames sind eine einmalige Systemeinrichtung und gehören daher ininitialize. Registry credentials sollten bei jedem regelmäßigen Build erneuert werden und gehören daher inmaintenance. Dieacme-CLI selbst fehlt hier bewusst. Sie liegt inacme-devtools, und Schritte auf Organisationsebene werden ausgeführt, bevor überhaupt ein Repository geklont wird. Deshalb wird sie über das Blueprint dieses Repositorys installiert (siehe unten). Diese Installation läuft während des Builds und bleibt im Snapshot erhalten, sodass jedes andere Repository sie verwenden kann. -
post-buildist der eigentliche Vorteil von Setups mit mehreren Repositorys. Es wird ausgeführt, nachdem jedes Repository geklont und eingerichtet wurde. Deshalb ist das der einzige Ort, an dem Sie prüfen können, ob der gesamte Stack gemeinsam hochfährt. Ein Exit-Code ungleich null lässt den Build fehlschlagen, sodass Sie einen fehlerhaften Stack schon zur Build-Zeit bemerken statt erst mitten in einer Sitzung. Siehepost-build. -
Secrets gehören in die Organisation, nicht in jedes einzelne Repository. Ein
ACME_REGISTRY_TOKENim Tab Secrets des Organisations-Blueprints reicht fürbundle installundnpm installin jedem Repository.
Die Repository-Blueprints
acme-devtools (repository blueprint)
acme-portal (repository blueprint)
acme-web, acme-sso und acme-events folgen demselben Schema: ein maintenance-Schritt für ihre jeweiligen Abhängigkeiten und knowledge-Einträge für ihre eigenen Lint-, Test- und Startbefehle.
Knowledge gilt pro Repository. Bei fünf konfigurierten Repositorys sieht eine Sitzung in
acme-portal die Knowledge-Einträge des Portals sowie Knowledge auf Organisations- und Enterprise-Ebene — die Einträge für acme-web sieht sie nicht. Deshalb sollte jedes Repository einen eigenen Blueprint haben, auch wenn sein maintenance-Abschnitt nur aus einer einzigen Zeile besteht.Wenn Ihre Services stattdessen in einem Monorepo liegen
Stufe 3: mehrere Organisationen — der Enterprise-Blueprint
- Der gesamte Datenverkehr läuft über einen Unternehmens-Proxy mit einer internen Zertifizierungsstelle.
- Alle Pakete kommen aus Artifactory, niemals aus öffentlichen Registries.
- In jeder Umgebung müssen die unternehmenseigenen Tools für Dependency- und Secret-Scans installiert sein.
- Python ist unternehmensweit 3.12 und Node.js 20, ohne Ausnahmen.
Devin's base environment (enterprise blueprint)
ARTIFACTORY_TOKEN ist ein Enterprise-Secret, das einmal unter Settings > Devins Basisumgebung > Secrets definiert wird und in jedem Build sowie in jeder Sitzung in allen Organisationen verfügbar ist. Das Zertifikat liegt als Dateianhang vor und wird dem Build als $FILE_ACME_CA_CERT zur Verfügung gestellt.
Wofür jetzt jede Ebene zuständig ist
Das Organisations-Blueprint von Payments aus Phase 2 funktioniert unverändert weiter. Es muss lediglich kein Python mehr installieren und keine Registries mehr konfigurieren, da die Enterprise-Ebene das bereits übernommen hat. Das Organisations-Blueprint von Data installiert Spark und ein JDK, mit denen Payments nie in Berührung kommt. Repository-Blueprints bleiben unverändert.
Im Betrieb
- Das Upgrade von Python 3.12 auf 3.13 erfordert nur eine einzeilige Änderung plus einen unternehmensweiten Rebuild, der an jede Organisation weitergegeben wird.
- Wenn ein Team andere Zugangsdaten benötigt — etwa weil die Data-Organisation ihre eigene Artifactory-Realm hat — definiert dieses Team ein Organisations-Secret mit demselben Namen, das das Enterprise-Secret überschreibt.
- Für eine schrittweise Einführung über mehrere Organisationen hinweg siehe Migration Ihres Enterprise-Kontos.
Entscheiden, wohin etwas gehört
1
Braucht jede Organisation im Unternehmen das?
→ Enterprise-Blueprint. Zertifikate, Proxys, interne Registries, vorgeschriebene Runtimes, Security-Tools und unternehmensweite Secrets.
2
Brauchen zwei oder mehr Repositories in dieser Organisation das?
→ Organisations-Blueprint. Docker, gemeinsam genutzte Entwicklungs-CLIs, lokale Hostnames, repository-übergreifende Service-Orchestrierung und Registry-Zugangsdaten. Prüfen Sie den zusammengestellten Stack in
post-build.3
Braucht nur dieses Repository das?
→ Repository-Blueprint. Abhängigkeitsinstallationen, Migrationen und die
knowledge-Einträge für die Lint-, Test- und Startbefehle.4
Ist es eine Tatsache und kein auszuführender Befehl?
→
knowledge, auf der jeweils passenden Ebene. Es wird nie ausgeführt; es wird in Devins Kontext geladen.- Alles in das Blueprint eines einzelnen Repositorys packen. Die anderen Repositories erhalten keine
knowledge-Einträge, und ein einzelner fehlerhafter Schritt lässt das gesamte Setup fehlerhaft wirken. - Gemeinsam genutzte Tools pro Repository duplizieren. Wenn zwei Repositories unterschiedliche Versionen desselben globalen Tools installieren, setzt sich die zuletzt ausgeführte durch. Platzieren Sie das Tool stattdessen im Organisations-Blueprint.
- Repository-übergreifende Überprüfung überspringen. Wenn Ihre Repositories nur gemeinsam funktionieren, ist
post-buildder einzige Ort, der das belegt — bevor eine Sitzung beginnt, statt erst währenddessen.
- Deklarative Konfiguration — Build-Reihenfolge, Snapshots und Fehlerbehebung
- Blueprint-Referenz — alle Felder, einschließlich
post-buildundclone - Vorlagenbibliothek — Blueprints zum Kopieren und Einfügen nach Sprache und Registry
- Workspaces und Monorepos — das Monorepo-Pendant zu Stufe 2
- Überblick über Enterprise-Umgebungen — Stufe 3 in allen Details

