メインコンテンツへスキップ
Enterprise 全体で Devin を運用するには、数十の組織と数百のリポジトリにわたる環境を管理する必要があります。このページでは、大規模運用で効果的なパターンと、避けるべき落とし穴を紹介します。

​
階層をまたいだブループリントの整理

Enterprise 管理者から最もよく寄せられる質問は、「この設定はどこに置くべきですか？」です。 答えはシンプルです。原則として、Enterprise ブループリントに入れてください。 Enterprise ブループリントは、すべての組織に適用されるもの (または適用される可能性があるもの) を置くのに最適な場所です。これには、言語ランタイム、セキュリティツール、社内証明書、社内 CLI、プロキシ設定、共有レジストリ認証が含まれます。すべての組織でそのすべてを利用するわけではなくても、ここに複数の言語やツールをインストールして問題ありません。
ブループリント階層利用するタイミング使用例
Enterprise共有設定全般のデフォルトPython 3.12, Node 20, Go 1.22, Rust, セキュリティスキャナー, 社内 CA 証明書, 社内 CLI, プロキシ設定, 共有レジストリトークン
Organization何かをすべての組織に適用すべきではない場合にのみ利用するチーム専用の非公開レジストリ, 特定のチームに制限されたツール, 組織固有の lint 設定
Repositoryリポジトリディレクトリで実行される、リポジトリごとのセットアップnpm install, uv sync, プロジェクト固有の Knowledge アイテム, リポジトリレベルの .envrc ファイル
Enterprise ブループリントではなく組織ブループリントを使う唯一の理由は、何かをすべての組織に適用したくない場合です。たとえば、あるチームが他のチームにはアクセスさせたくない非公開の npm レジストリを利用している場合、そのレジストリ設定は Enterprise ブループリントではなく、そのチームの組織ブループリントに置くべきです。 すべての組織に適用されるものは Enterprise に置きます。リポジトリ固有のものは、リポジトリのブループリントに置きます。組織階層は、その中間にある例外のためだけに存在します。
リポジトリ固有のコマンド (npm install など) を Enterprise や組織ブループリントに入れないでください。これらの階層はリポジトリディレクトリではなくホームディレクトリで実行されるため、リポジトリ固有のコマンドは失敗するか、 誤った場所にインストールされます。

​
適切な階層でKnowledge アイテムを利用する

Knowledge アイテムは階層をまたいで累積的に適用され、Devin はそのすべてを参照します。これを利用して、ガイダンスを階層的に整理できます。
  • Enterprise knowledge: 全社共通のコーディング規約、セキュリティレビューの要件、社内ドキュメントへのリンク。
  • Org knowledge: チームの慣習、共有ライブラリの利用方法、チーム固有のデプロイ手順。
  • Repo knowledge: 特定のプロジェクトの lint、test、build コマンド。

​
大規模環境でのシークレット管理

シークレットはブループリントと同じ階層に従って継承され、より具体的なシークレットが優先されます。

​
シークレットを定義する場所

Secret scopeUse for使用例
Enterpriseすべての組織で共有する認証情報社内レジストリのトークン、社内プロキシの認証、社内サービス向けの共通APIキー
Organizationチーム固有の認証情報チームのデプロイキー、チームのサービス向けAPIトークン、チーム固有のレジストリ認証
Repositoryリポジトリ固有の認証情報プロジェクトごとのAPIキー、プロジェクト固有のサービスアカウント
シークレットは、該当する中で最も上位の階層に配置してください。 すべての組織が社内 npm レジストリへのアクセスを必要とする場合は、トークンを Enterprise シークレットとして一度だけ定義します。50 個の組織設定に重複して定義しないでください。

​
シークレットの衛生管理

  • シークレットを YAML に絶対に含めないでください。 必ずシークレット管理 UI を利用してください。YAML に記載したシークレットは、ログ、ビルド成果物、監査証跡に残ってしまいます。
  • シークレットは定期的にローテーションしてください。 UI でシークレットをローテーションすると、新しい値は次回のビルドから有効になります。ブループリント を変更する必要はありません。
  • わかりやすい名前を付けてください。 INTERNAL_NPM_TOKEN は TOKEN_1 より適切です。ほかの管理者 (や将来の自身) が、各シークレットの用途を理解できるようにする必要があります。
  • シークレットの利用状況を監査してください。 定期的に、どのシークレットが存在するか、今も必要かどうかを確認してください。使われていないシークレットは削除し、攻撃対象領域を減らしましょう。
org シークレットと Enterprise シークレットの名前が同じ場合は、org シークレットが優先されます。repo シークレットが org シークレットを上書きする場合も同様です。これは意図して利用してください。たとえば、org では Enterprise のレジストリトークンを、異なる権限を持つチーム専用のトークンで上書きすることがあります。

​
ビルドの健全性の監視

大規模な運用では、ビルドの失敗は避けられません。重要なのは、それらを早期に検知し、迅速に解消することです。

​
レビューの実施頻度を決める

すべての組織で、毎週ビルドの健全性を確認します。確認するポイントは次のとおりです。
  • 失敗したビルド: Enterprise または組織のブループリントで発生した重大な失敗。すべてのリポジトリをブロックします。
  • 部分的なビルド: 一部のリポジトリのみが失敗している状態。多くの場合、依存関係の問題や古いブループリントの兆候です。
  • 古いビルド: 最新のビルドが異常に古い組織。ビルドキューが滞留している可能性があります。

​
Enterprise ブループリント の障害に対処する

Enterprise ブループリント の変更によって広範囲で障害が発生した場合:
  1. 影響範囲を把握します。 Rollout ページで、影響を受けている org の数を確認します。
  2. Enterprise ブループリント を元に戻します。 直近で正常に動作していた ブループリント に戻し、すぐに保存してください。これにより、影響を受けたすべての org で再ビルドがトリガーされます。
  3. 切り分けて調査します。 変更を再度ロールアウトする前に、単一のパイロット org でテストします。
壊れた Enterprise ブループリント をデバッグしながら、そのままにしておかないでください。壊れている間も、org では失敗したビルドが発生し続けます。

​
部分的なビルドは兆候です

部分的なビルドとは、org 内の一部の repo では成功し、他では失敗している状態を意味します。通常、原因は次のいずれかです。
  • repo 固有の依存関係の問題 (壊れたロックファイル、削除されたパッケージ)
  • 特定のプロジェクトでのみ必要なシステムライブラリの不足
  • repo の変更に合わせて更新されていない古いブループリント
部分的なビルドでも、成功した repo については利用可能なスナップショットが生成されます。ただし、失敗したものは調査してください。放置すると問題が蓄積しがちです。

​
ビルドをピン留めするべき場合

ビルドをピン留めすると、org の環境は特定のスナップショットに固定されます。慎重に利用してください。

​
固定するのが適切なケース

  • 重要なリリース作業の進行中。 リリース対応中の今後48時間は、安定していて正常に動作することが確認済みの環境が必要です。
  • アクティブなデバッグ。 ビルドの問題を調査しており、自動更新で状況が変わってしまうのを避けたい場合です。
  • ロールバック。 新しいビルドでリグレッションが発生し、blueprintを修正している間、すぐに元に戻す必要がある場合です。

​
ピン留めすべきでない理由

  • 対処を避けるため。 ビルドが壊れている場合は、ブループリントを修正してください。ピン留めは問題を見えなくするだけで、しかもピンは自動で期限切れにならないため、うっかり忘れると古い環境をいつまでも使い続けることになります。
  • 「念のため」。 自動更新により依存関係は常に最新の状態に保たれ、問題も早い段階で見つかります。明確な理由もなくこれを無効にすると、問題を先送りにするだけです。
ピン留めできるのは、7日以内のビルドに限られます。いったんピン留めすると、手動で削除するまでそのピンはアクティブなままです。期限切れにはなりません。ピンを忘れると、チームはますます古くなった スナップショット上で稼働し続けることになります。

​
Enterprise の移行

推奨される段階的な移行プレイブック (初期テストから本番展開まで) については、Enterprise の移行を参照してください。

​
一般的なアーキテクチャパターン

企業ごとに構成が異なるため、適したブループリント戦略も異なります。

​
モノレポ構成の組織

セットアップ: 複数のプロジェクトを含む1つの大規模なリポジトリを持つ1つの組織。 アプローチ: Enterprise ブループリント で、共有のツール類 (ランタイム、グローバル CLI ツール、レジストリ) をすべて扱います。プロジェクト固有のセットアップ (フロントエンド ディレクトリでの npm install、バックエンド ディレクトリでの uv sync) は repo ブループリント に記述します。org ブループリント が必要なのは、この組織に他の組織には適用すべきでないツールや設定がある場合だけです。 
# モノレポ用のリポブループリント
maintenance:
  - name: "Frontend dependencies"
    run: (cd frontend && npm install)

  - name: "Backend dependencies"
    run: (cd backend && uv sync)

knowledge:
  - name: lint
    contents: |
      Frontend: cd frontend && npm run lint
      Backend: cd backend && uv run ruff check .

​
複数リポジトリの組織

セットアップ: 複数の関連リポジトリを持つ組織 (例: マイクロサービスチーム) 。 アプローチ: 共有のツールとレジストリ設定は org ブループリント にまとめます。各リポジトリには、それぞれ maintenance と knowledge だけを含む専用の ブループリント を用意します。これにより、リポジトリ間でセットアップコマンドを重複して記述せずに済みます。

​
共有インフラストラクチャ org

セットアップ: 他のチームが利用する共有サービスを提供する、プラットフォームまたは DevOps の org。 アプローチ: enterprise ブループリント で共通の基盤をカバーします。共有インフラ org の ブループリント には、その repo で必要なプラットフォーム固有のツール (Terraform、kubectl、クラウド CLI) がインストールされます。他の org にはこれらのツールは含まれません。適用されるのは、enterprise ブループリント の内容に加えて各 org 固有の設定のみです。

​
独立したプロジェクト組織

セットアップ: 基本的なものを除き、共有ツールを持たない独立したチーム。 アプローチ: Enterprise ブループリント は引き続き共通基盤を担います。具体的には、標準的な言語ランタイム、セキュリティツール、企業のインフラストラクチャなどです。各組織は、そのチームに本当に固有で、ほかの組織と共有すべきでないツールや設定に限って、独自の ブループリント を利用します。リポジトリの ブループリント は、プロジェクトごとのセットアップを扱います。
判断に迷う場合は、Enterprise ブループリント に含めてください。組織ごとに何かを除外する明確な理由 (ツールのバージョン競合、アクセス制限など) がある場合は、組織レベルで上書きできます。多くの組織の ブループリント ごとにセットアップを重複させるより、包括的な Enterprise のベースラインを用意するほうが簡単です。