先に大まかな目安を示すと、リポジトリ ブループリントはプロジェクトの依存関係をインストールし、組織ブループリントは複数のリポジトリで共有するものをインストールし、Enterprise ブループリントはすべての組織で必須のものをインストールします。 ティアは追加式で、上位から順に適用されます: Enterprise → 組織 → リポジトリをクローン → リポジトリ。
ステージ 1: 1 つのリポジトリ
acme-web があります。これは Postgres と Redis を使用する Rails アプリケーションです。エンジニアは 2 人、リポジトリは 1 つです。まだ共有すべきものはないため、すべてリポジトリブループリントに記述します。
設定 > 環境 > ブループリント > 追加 でリポジトリを追加し、その Editor を開いて、次のように記述します。
acme-web (repository blueprint)
2 年後、ACME には 5 つのリポジトリがあります。
これは興味深いケースです。というのも、これらのリポジトリは 独立していない からです。
acme-devtools がインストールされ、acme-sso が動作していなければ、acme-portal では意味のある作業はできません。ここで 2 つの疑問が生じます。
「アプリケーションごとに 1 つのブループリントが必要ですか? それとも開発 CLI 用に 1 つだけで十分ですか?」
- 5 つのリポジトリすべてを環境に追加し、すべてがスナップショットにクローンされるようにします。
- リポジトリ間で共有するセットアップは、組織ブループリントに 1 回だけ記述します。たとえば、言語ランタイム、Docker、ローカルのホスト名、内部レジストリ用の認証情報です。
- 各リポジトリには、そのリポジトリ固有の依存関係と固有の
Knowledgeエントリ (lint、test、起動コマンド) のために、それぞれ専用のリポジトリブループリントを持たせます。
acme-devtools ブループリントにまとめるべきでない理由は次のとおりです。リポジトリブループリントは、すべてのリポジトリのクローンが完了したあとに実行されますが、そのステップはそのリポジトリのディレクトリ内で実行され、Knowledge エントリも Devin がそのリポジトリで作業しているときにのみ読み込まれます。acme-devtools がすべてをインストールしてしまうと、acme-portal で作業するセッションからは portal の lint コマンドや test コマンドがまったく見えません。さらに、acme-devtools の 1 つのステップが失敗すると、ほかの 4 つのリポジトリは正常に見えても、実際には使えない状態になってしまいます。
組織のブループリント
Organization-wide setup
-
initializeとmaintenanceの違い。 Docker、ランタイム、ホスト名は 1回限り のシステム設定なので、initializeに含めます。レジストリ認証情報は定期ビルドのたびに更新する必要があるため、maintenanceに含めます。acmeCLI 自体をここに含めていないのは意図的です。これはacme-devtoolsの中にあり、組織のステップはどのリポジトリもクローンされる前に実行されるため、そのリポジトリ自身のブループリントからインストールします (以下に記載) 。このインストールはビルド中に実行され、スナップショットにも保持されるため、他のすべてのリポジトリから利用できます。 -
post-buildは複数リポジトリ構成の真価を発揮する場所です。 これは すべての リポジトリのクローンとセットアップが完了した後に実行されるため、スタック全体がまとめて起動することを検証できる唯一の場所です。終了コードが 0 以外だとビルドは失敗するので、セッションの途中ではなくビルド時点でスタックの不具合に気づけます。post-buildを参照してください。 -
シークレットは各リポジトリではなく組織に属します。 組織ブループリントの Secrets タブにある 1 つの
ACME_REGISTRY_TOKENで、すべてのリポジトリのbundle installとnpm installをまかなえます。
各リポジトリのブループリント
acme-devtools (repository blueprint)
acme-portal (repository blueprint)
acme-web、acme-sso、acme-events も同じ構成です。つまり、それぞれ独自の依存関係に対する maintenance ステップと、それぞれの lint、テスト、起動コマンド用の Knowledge エントリがあります。
Knowledge はリポジトリ単位です。 5 つのリポジトリが設定されている場合、
acme-portal で作業するセッションから参照できるのは、portal の Knowledge エントリに加えて、組織と Enterprise の Knowledge です。acme-web のエントリは参照できません。だからこそ、maintenance セクションが 1 行だけでも、各リポジトリに専用のブループリントが必要です。代わりにサービスをモノレポで管理している場合
ステージ 3: 複数の組織 — Enterprise ブループリント
- すべてのトラフィックは、社内認証局を備えた企業のプロキシを経由します。
- すべてのパッケージは Artifactory から取得し、公開レジストリからは取得しません。
- すべての環境に、社内の依存関係スキャンツールとシークレットスキャンツールをインストールする必要があります。
- Python は 3.12、Node.js は 20 で全社統一とし、例外は認められません。
Devin's base environment (enterprise blueprint)
ARTIFACTORY_TOKEN は enterprise secret で、Settings > Devin’s base environment > Secrets で一度定義すれば、すべての組織のあらゆるビルドとセッションで利用できます。証明書はファイル添付として、ビルドには $FILE_ACME_CA_CERT として渡されます。
各ティアの現在の担当範囲
Stage 2 の Payments 組織ブループリントは変更なしでそのまま動作します。Enterprise ティアですでに対応しているため、Python のインストールやレジストリの設定は不要になっただけです。Data の組織ブループリントは Spark と JDK をインストールしますが、Payments には適用されません。リポジトリブループリントに変更はありません。
運用
- Python を 3.12 から 3.13 にアップグレードする場合は、1 行編集して Enterprise 全体の再ビルド を実行するだけで、その変更はすべての組織に反映されます。
- あるチームで別の認証情報が必要な場合 — たとえば Data 組織が独自の Artifactory realm を持っている場合 — そのチームは同じ名前の組織シークレットを定義し、それが Enterprise シークレットをオーバーライドします。
- これを組織間で段階的に展開するには、Enterprise の移行 を参照してください。
何をどこに置くかを決める
1
会社内のすべての組織で必要ですか?
→ Enterprise blueprint. 証明書、プロキシ、社内レジストリ、必須ランタイム、セキュリティツール、全社共通のシークレット。
2
この組織内の2つ以上のリポジトリで必要ですか?
→ Organization blueprint. Docker、共有の開発用 CLI、ローカルホスト名、リポジトリ横断のサービスオーケストレーション、レジストリ認証情報。構成したスタックは
post-build で検証してください。3
このリポジトリだけで必要ですか?
→ Repository blueprint. 依存関係のインストール、マイグレーション、lint・test・起動コマンド用の
Knowledge エントリ。4
実行するコマンドではなく、事実ですか?
→
Knowledge。該当するティアに配置します。これは実行されず、Devinの前提情報に読み込まれます。- すべてを1つのリポジトリのブループリントに入れてしまうこと。 他のリポジトリには
Knowledgeエントリが行き渡らず、1つの壊れたステップのせいでセットアップ全体が不調に見えてしまいます。 - 共有ツールをリポジトリごとに重複して入れてしまうこと。 2つのリポジトリが同じグローバルツールの異なるバージョンをインストールすると、最後に実行されたものが有効になります。代わりに、そのツールは組織ブループリントに置いてください。
- リポジトリ横断の検証を省略すること。 リポジトリ同士が連携して初めて動く場合、それをセッション開始前に確認できるのは
post-buildだけです。
- 宣言的構成 — ビルドの順序、スナップショット、トラブルシューティング
- ブループリント リファレンス —
post-buildとcloneを含むすべてのフィールド - テンプレート ライブラリ — 言語やレジストリごとに使えるコピーペースト用ブループリント
- ワークスペースとモノレポ — Stage 2 のモノレポ版
- Enterprise 環境の概要 — Stage 3 の詳細を網羅

