Skip to main content
Blueprints haben drei Ebenen — Repository, Organisation und Enterprise — und die häufigste Frage ist: In welche Ebene gehört das? Diese Seite beantwortet diese Frage anhand eines fiktiven Unternehmens, ACME Corp, in drei Wachstumsphasen. Jede Phase bringt genau ein neues Problem mit sich, und jedes Problem wird durch die jeweils nächsthöhere Ebene gelöst. Springen Sie zu der Phase, die Ihrem Unternehmen am ehesten entspricht.
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 hat ein Produkt: 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)
Das ist die gesamte Konfiguration. Sie speichern sie, ein Build wird ausgeführt, und jede Sitzung startet mit installiertem Ruby, laufendem Postgres, installierten Gems und ausgeführter Datenbankmigration. Warum noch kein Organisations-Blueprint? Ein Organisations-Blueprint, der nur für ein Repository verwendet wird, ist bloß eine zusätzliche Abstraktionsebene. Warten Sie, bis ein zweites Repository dasselbe braucht.
ACME hat das nicht von Hand verfasst. Sie haben Devin “Richte deine Umgebung für dieses Repository ein” gefragt, die Vorschlagskarte geprüft und auf Approve geklickt. Siehe Erste Schritte.

Phase 2: mehrere Repositories mit gemeinsamen Abhängigkeiten

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

Beides — sie erfüllen unterschiedliche Aufgaben. Devin erstellt einen Snapshot, der alle konfigurierten Repositories enthält, daher ist das keine Entweder-oder-Entscheidung:
  • 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).
Darum sollten Sie nicht alles im 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
Drei Dinge sind dabei wichtig:
  1. initialize versus maintenance. Docker, Runtimes und Hostnames sind eine einmalige Systemeinrichtung und gehören daher in initialize. Registry credentials sollten bei jedem regelmäßigen Build erneuert werden und gehören daher in maintenance. Die acme-CLI selbst fehlt hier bewusst. Sie liegt in acme-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.
  2. post-build ist 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. Siehe post-build.
  3. Secrets gehören in die Organisation, nicht in jedes einzelne Repository. Ein ACME_REGISTRY_TOKEN im Tab Secrets des Organisations-Blueprints reicht für bundle install und npm install in jedem Repository.
Wichtiger Hinweis zur Reihenfolge: initialize und maintenance auf Organisationsebene werden beide ausgeführt, bevor Repositories geklont werden (siehe Build-Reihenfolge). Alles, was ausgecheckten Quellcode benötigt — etwa eine CLI, die in einem Ihrer Repositories liegt — muss in das Blueprint dieses Repositorys oder in post-build, nicht in maintenance auf Organisationsebene. Belassen Sie es nur dann auf der Organisationsebene, wenn Sie es aus einem veröffentlichten Artefakt installieren können, etwa aus einem Tarball, einem Package oder einem Container-Image.

Die Repository-Blueprints

Jedes Repository-Blueprint bleibt kompakt, da alles gemeinsam Genutzte bereits vorhanden ist:
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.
acme-devtools in der Repository-Liste an erste Stelle setzen. Repository-Blueprints werden in der in Settings angezeigten Reihenfolge ausgeführt. Daher sollte das Repository, das die gemeinsam genutzte CLI bereitstellt, vor den Repositorys eingerichtet werden, die sie aufrufen.
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.
Da die acme-CLI bereits weiß, wie alles ausgeführt wird, ist der wertvollste Teil dieser Blueprints der Abschnitt knowledge: Er zeigt Devin, welchen CLI-Befehl es verwenden soll. Verweise dort auf eure interne Dokumentationssuche, falls ihr eine habt.

Wenn Ihre Services stattdessen in einem Monorepo liegen

Die Idee ist dieselbe, nur eine Ebene tiefer: Verwenden Sie Workspaces, um jedem Paket innerhalb eines einzelnen Repositorys ein eigenes Setup und eigenes Knowledge im jeweiligen Geltungsbereich zu geben, anstatt eines Blueprints pro Repository.

Stufe 3: mehrere Organisationen — der Enterprise-Blueprint

ACME hat inzwischen 400 Ingenieure. Platform, Payments und Data haben jeweils ihre eigene Devin-Organisation, mit separaten Repositories, separaten Mitgliedern und separaten Snapshots. Ein Sicherheitsteam hat Anforderungen, die für alle gelten:
  • 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.
Nichts davon gehört in ein Organisations-Blueprint, denn dann müsste es in jede Organisation kopiert werden, und es würde in dem Moment voneinander abweichen, in dem ein Team vergisst, es zu aktualisieren. Genau dafür gibt es das Enterprise-Blueprint: eine Basisumgebung, die in jedem Build jeder Organisation im gesamten Enterprise zuerst ausgeführt wird.
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

Gehen Sie die Liste der Reihe nach durch. Das erste „Ja“ ist die Antwort:
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.
Häufige Fehler, die dadurch vermieden werden:
  • 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-build der einzige Ort, der das belegt — bevor eine Sitzung beginnt, statt erst währenddessen.