Skip to main content
ブループリントには、リポジトリ、組織、Enterprise の 3 つのティアがあります。そこで最もよくあるのが、これはどのティアに置くべきか? という疑問です。 このページでは、架空の企業 ACME Corp の成長を 3 つの段階に沿って追いながら、その答えを示します。各段階で新しく生じる問題は 1 つだけで、その問題は 1 つ上のティアで解決されます。自社に近い段階から読んでください。
先に大まかな目安を示すと、リポジトリ ブループリントはプロジェクトの依存関係をインストールし、組織ブループリントは複数のリポジトリで共有するものをインストールし、Enterprise ブループリントはすべての組織で必須のものをインストールします。 ティアは追加式で、上位から順に適用されます: Enterprise → 組織 → リポジトリをクローン → リポジトリ。

ステージ 1: 1 つのリポジトリ

ACME には 1 つの製品、acme-web があります。これは Postgres と Redis を使用する Rails アプリケーションです。エンジニアは 2 人、リポジトリは 1 つです。まだ共有すべきものはないため、すべてリポジトリブループリントに記述します 設定 > 環境 > ブループリント > 追加 でリポジトリを追加し、その Editor を開いて、次のように記述します。
acme-web (repository blueprint)
これで設定は完了です。保存するとビルドが実行され、以後はすべてのセッションが、Ruby のインストール、Postgres の起動、gem のインストール、データベースのマイグレーションが済んだ状態で起動します。 なぜまだ組織ブループリントがないのですか? 1 つのリポジトリにしか使わない組織ブループリントは、単に階層を増やすだけです。同じ設定を必要とする 2 つ目のリポジトリが出てきたら導入しましょう。
ACME はこれを手作業で書いたわけではありません。Devin に “set up your environment for this repository” と依頼し、提案カードを確認して 承認 をクリックしました。はじめに を参照してください。

ステージ 2: 依存関係を共有する複数のリポジトリ

2 年後、ACME には 5 つのリポジトリがあります。 これは興味深いケースです。というのも、これらのリポジトリは 独立していない からです。acme-devtools がインストールされ、acme-sso が動作していなければ、acme-portal では意味のある作業はできません。ここで 2 つの疑問が生じます。

「アプリケーションごとに 1 つのブループリントが必要ですか? それとも開発 CLI 用に 1 つだけで十分ですか?」

どちらも必要です。役割が異なるためです。 Devin は、設定済みのすべてのリポジトリを含む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
注目すべき点は 3 つあります。
  1. initializemaintenance の違い。 Docker、ランタイム、ホスト名は 1回限り のシステム設定なので、initialize に含めます。レジストリ認証情報は定期ビルドのたびに更新する必要があるため、maintenance に含めます。 acme CLI 自体をここに含めていないのは意図的です。これは acme-devtools の中にあり、組織のステップはどのリポジトリもクローンされる前に実行されるため、そのリポジトリ自身のブループリントからインストールします (以下に記載) 。このインストールはビルド中に実行され、スナップショットにも保持されるため、他のすべてのリポジトリから利用できます。
  2. post-build は複数リポジトリ構成の真価を発揮する場所です。 これは すべての リポジトリのクローンとセットアップが完了した後に実行されるため、スタック全体がまとめて起動することを検証できる唯一の場所です。終了コードが 0 以外だとビルドは失敗するので、セッションの途中ではなくビルド時点でスタックの不具合に気づけます。post-build を参照してください。
  3. シークレットは各リポジトリではなく組織に属します。 組織ブループリントの Secrets タブにある 1 つの ACME_REGISTRY_TOKEN で、すべてのリポジトリの bundle installnpm install をまかなえます。
順序に関する注意: 組織の initializemaintenance はどちらもリポジトリがクローンされる前に実行されます (build order を参照) 。チェックアウト済みのソースを必要とするもの、たとえば自分のリポジトリの 1 つの中にある CLI は、組織の maintenance ではなく、そのリポジトリのブループリントまたは post-build に入れる必要があります。tarball、パッケージ、コンテナイメージなどのリリース済みアーティファクトからインストールできる場合にのみ、組織ティアに置いてください。

各リポジトリのブループリント

共有するものはすべてすでに存在しているため、各リポジトリのブループリントは小規模なままです。
acme-devtools (repository blueprint)
acme-portal (repository blueprint)
acme-webacme-ssoacme-events も同じ構成です。つまり、それぞれ独自の依存関係に対する maintenance ステップと、それぞれの lint、テスト、起動コマンド用の Knowledge エントリがあります。
リポジトリ一覧では acme-devtools を最初 に配置してください。リポジトリのブループリントは Settings に表示されている順に実行されるため、共有 CLI を提供するリポジトリは、それを呼び出すリポジトリより先にセットアップしておく必要があります。
Knowledge はリポジトリ単位です。 5 つのリポジトリが設定されている場合、acme-portal で作業するセッションから参照できるのは、portal の Knowledge エントリに加えて、組織と Enterprise の Knowledge です。acme-web のエントリは参照できません。だからこそ、maintenance セクションが 1 行だけでも、各リポジトリに専用のブループリントが必要です。
acme CLI はすでにあらゆる実行方法を把握しているため、これらのブループリントで最も価値が高いのは Knowledge セクションです。ここでは、どの CLI コマンドを使えばよいかを Devin に教えられます。社内向けのドキュメント検索がある場合は、そこを参照するよう指定してください。

代わりにサービスをモノレポで管理している場合

考え方は同じで、適用先が1つ下のティアになるだけです。リポジトリごとに1つのブループリントを使うのではなく、ワークスペースを利用して、単一のリポジトリ内で各パッケージごとに専用のセットアップとKnowledgeを持たせます。

ステージ 3: 複数の組織 — Enterprise ブループリント

ACME には現在 400 人のエンジニアがいます。Platform、Payments、Data はそれぞれ独自の Devin 組織 を持ち、リポジトリもメンバーもスナップショットも別々に管理されています。さらに、それらすべてに共通して適用される要件がセキュリティチームから定められています。
  • すべてのトラフィックは、社内認証局を備えた企業のプロキシを経由します。
  • すべてのパッケージは Artifactory から取得し、公開レジストリからは取得しません。
  • すべての環境に、社内の依存関係スキャンツールとシークレットスキャンツールをインストールする必要があります。
  • Python は 3.12、Node.js は 20 で全社統一とし、例外は認められません。
こうした内容を組織ブループリントに入れるべきではありません。そうすると すべての組織にコピーする 必要があり、どこか 1 つのチームが更新を忘れた時点で内容にずれが生じてしまうからです。そこで使うのが Enterprise ブループリント です。これは企業全体のベース環境として、すべての組織のビルドで最初に実行されます。
Devin's base environment (enterprise blueprint)
ARTIFACTORY_TOKENenterprise 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 だけです。