はじめに
前提条件: 環境を設定する前に、Devin があなたのリポジトリにアクセスできる必要があります。Git 統合がまだ設定されていない場合は、設定手順について 開始前に を参照してください。Enterprise ユーザーは、Enterprise Settings > Repository Permissions で各組織に対応するリポジトリへのアクセスも付与する必要があります。
- Devin に任せる（推奨）
- 手動セットアップ
ほとんどのユーザーに最適です。Devin がリポジトリを調査し、必要なツール、ランタイム、依存関係を判断して、ブループリントを生成します。ビルドが開始される前に、提案されたセットアップを確認して承認します。Environment ハブの1 つのプロンプトによるセットアップ動画と概要を参照してください。
1
Devin セッションを開始する
新しいセッションを開き、Devin にリポジトリの設定を依頼します。たとえば、“このリポジトリの環境を設定してください。“
2
確認して承認する
Devin が検出した内容に基づいてブループリントを提案します。タイムラインに suggestion cards が表示されるので、提案されたツール、依存関係、コマンドを確認してから Approve をクリックしてください。
3
ビルドして確認する
提案を承認すると、ビルドが実行されてスナップショットが生成されます。新しいセッションを開始してそのスナップショットから起動し、lint や test のコマンドを実行するよう Devin に依頼して、問題なく動作することを確認してください。
最初から最後までの適用例を見る
Scenarios: growing with ACME Corp — 1 つのリポジトリから始め、次に共有依存関係を持つ複数のリポジトリ、さらに複数の組織へと拡張していきます。各段階に対応する実用的なブループリントと、どのティアに何を配置すべきかを判断する方法を紹介します。
仕組み
宣言的構成では、3 つの概念を使用します。
ブループリント は必要な内容を記述します。 これらはユーザーが作成し、Settings UI で編集します。
ビルド は ブループリント を実行して スナップショット を生成します。 ビルド は ブループリント を保存すると自動的に実行され、dependencies を最新の状態に保つために定期的 (約 24 時間ごと) にも実行されます。
スナップショット はセッションの起動元です。 各組織には 1 つのアクティブな スナップショット があります。すべてのセッションはクリーンなコピーから起動します。セッションでの changes は スナップショット には保持されません。
ブループリント のセクション
ブループリント には 3 つの中核セクションに加え、組織/enterprise のブループリント用にpost-build ブロック、リポジトリレベル のブループリント用に任意の clone ブロックがあります。
initialize は、一度だけ実行すればよい処理のためのセクションです。たとえば、言語実行環境、システムパッケージ、グローバル CLI ツールなどです。
maintenance は、常に最新の状態に保つ必要がある依存関係のインストール向けです。ビルド時に実行され、セッション開始時にはエージェントに提示されるため、依存関係が変更されていれば再実行できます (たとえば最新コードを pull した後など)。コマンドはセッション開始時に自動実行されませんが、それでも高速で増分的なものにしてください (npm ci ではなく npm install を利用する) 。
knowledge は参照情報であり、実行はされません。ここで、lint、test、build の正しいコマンドを Devin に伝えます。項目は簡潔に保ち、実行可能なコマンドに絞ってください。
post-build (組織-level および enterprise-level のみ) は、すべてのリポジトリの クローン とセットアップが完了した後、スナップショットが保存される直前に実行されます。これを利用して、構成済みの環境を検証してください。たとえば、必要なツールがインストールされているか、複数リポジトリにまたがるスモークテストが通るかを確認できます。終了コードが 0 以外の場合、ビルドは失敗するため、チェックを通過していないスナップショットが出荷されることはありません。ブループリントリファレンス → post-build を参照してください。
clone (リポジトリレベル のみ) は、リポジトリをスナップショットに クローン する際に Devin が利用するデフォルトを上書きします。たとえば、デフォルト以外のブランチをチェックアウトする (ref)、クローン 先 (path) を変更する、またはサブモジュールや LFS オブジェクトをスキップする、といったことができます。各フィールドは任意です。完全なフィールド一覧については、ブループリントリファレンス → クローン を参照してください。
ここでの Knowledge と Knowledge プロダクト機能の違い: ブループリント 内の
knowledge セクションは、環境に紐づいた短いコマンド参照のためのものです。アーキテクチャドキュメント、慣例、チームの
ワークフローには、代わりに独立した スキル 機能を利用してください。複数ドキュメント YAML: ブループリントエディタは、
--- 区切りを使った複数ドキュメント YAML をサポートしています。これにより、複雑なブループリントを 1 つのエディタ内で論理的なセクションに整理できます。ブループリント の適用範囲
ブループリント は次の 2 つのレベルで定義できます。
ブループリント は追加式です。リポジトリブループリント は、組織の ブループリント を基盤としてその上に追加されます。リポジトリの
maintenance では、組織の initialize でインストールされたツールを利用できます。特定のツールが 1 つのリポジトリでのみ必要な場合は、そのリポジトリの ブループリント に追加してください。すべてのリポジトリで必要な場合は、組織の ブループリント に追加してください。
モノレポでは、リポジトリにルートブループリントと、サブディレクトリごとのワークスペースブループリントを設定できます。各ワークスペースブループリントには、それぞれ独自の initialize、maintenance、knowledge セクションと作業ディレクトリを設定できます。セットアップ手順と使用例については、ワークスペースとモノレポ を参照してください。
コードベースの拡大に応じてどのティアを選ぶかについての具体的な使用例は、Scenarios: growing with ACME Corp を参照してください。
Enterprise ユーザー: 3 つ目の階層として、すべての組織に適用される Enterprise ブループリント があります。詳しくは Enterprise environment overview を参照してください。
ビルドとセッション
スナップショット
組織には1つのアクティブなスナップショットがあります。これは、ツール、リポジトリ、依存関係があらかじめインストールされた VM イメージです。設定されたすべてのリポジトリは、この単一のイメージ内にクローンされ、セットアップされます。各セッションはクリーンなコピーから起動します。ビルドの仕組み
ビルドでは、ブループリントを順に実行して新しいスナップショットを作成します。セッションの仕組み
各セッションは、スナップショットのクリーンなコピーで起動します。セッションが終了すると、すべての変更は破棄されます。セッション開始時には、次の処理が行われます。- 対象のリポジトリの最新コードが取得されます。
maintenanceコマンド (Enterprise、組織、リポジトリ) は前提情報としてエージェントに提示されますが、自動実行はされません。前回のビルド以降に依存関係が変更されたことをエージェントが検出した場合は、これらを再実行することがあります。- そのリポジトリの
knowledgeエントリが Devin の前提情報に読み込まれます。
Knowledge はリポジトリ単位です。 5 つのリポジトリを設定している場合、Devin が参照できるのは現在作業中のリポジトリの Knowledge エントリだけです。
ビルドがトリガーされる条件
一度に実行できるビルドは 1 つだけです。新しいトリガーが発生すると、キューに入っているビルドはキャンセルされ、新しいビルドが最初から開始されます。
ビルドステータス
Partial ビルドでも、使用可能なスナップショットが生成されます。すべてのリポジトリはクローンされるため、すべてのソースコードをセッションで利用できます。実行されないのは、失敗したブループリントのセットアップ手順のみです。5つのリポジトリのうち1つのブループリントに問題がある場合でも、残りの4つは完全にセットアップされ、Devinは5つ目のリポジトリを読み取って作業できます。
環境の管理
リポジトリの状態
リポジトリは、Environment の設定画面で次の 3 つの状態で表示されます。
Included と Configured の違い: 「Included」のリポジトリはクローンされているため Devin はコードにアクセスできますが、カスタムのセットアップコマンドはありません。一方、「Configured」のリポジトリには、initialize/maintenance/knowledge の instructions が明示的に設定されています。
シークレット
$VARIABLE_NAME 構文でシークレットを参照します。追加するには、ブループリントエディタ内の シークレット タブを開きます。
initialize 中にコマンドがシークレットの値を設定ファイルに書き込んだ場合、その値はスナップショットに残ります。認証情報を書き込む手順は maintenance に配置し、定期ビルド時に更新されるようにしてください。
シークレットのスコープと挙動の詳細については、ブループリントリファレンス を参照してください.
複数のリポジトリ
各リポジトリにはそれぞれ専用のブループリントが割り当てられます。ビルド中は、すべてのリポジトリが同じスナップショット内でセットアップされ、別々のディレクトリにクローンされ、依存関係もそれぞれ個別にインストールされます。 2つのリポジトリがグローバルツールの異なるバージョンをインストールしたり、共有ファイル (~/.bashrc など) を変更したりすると、最後に実行されたものが反映されます。競合を避けるには、共有ツールのインストールを組織全体のブループリントにまとめてください。
GitHub Actions
ツールや実行環境をインストールするためのシェルスクリプトを作成する代わりに、ブループリントで GitHub Actions を直接参照できます。Devin はビルド中にそのアクションをダウンロードして実行します。これは、GitHub の CI ランナーがアクションのステップを実行するのと同じ仕組みです。setup-python、setup-node、setup-go といった言語セットアップ用アクションで役立ちます。
構文の詳細、使用例、制限事項については、ブループリントでのGitHub Actionsを参照してください。
モノレポ
サブシェルを使えばサブディレクトリでコマンドを実行でき、個々のパッケージ向けに専用のワークスペース単位のブループリントを作成することもできます。Devin はパッケージごとの Knowledge エントリにも対応しているため、各ワークスペースでそれぞれ独自の lint、test、build コマンドを設定できます。 セットアップ手順と使用例については、ワークスペースとモノレポを参照してください。ピン留めと自動更新
デフォルトでは、Devin は最新の成功したビルドのスナップショットを利用します。ピン留めを使うと、特定のビルドのスナップショットに固定できます。これは、新しいビルドで不具合が発生した場合や、一連のセッションで環境を固定したい場合に便利です。 ピン留めするには: Settings > Environment > Snapshots に移動し、履歴内で対象のビルド (success または partial で、7 日以内のもの) を見つけ、そのメニューを開いて Use this build をクリックします。ピン留め中は定期的な更新がスキップされ、そのビルドには Locked のバッジが付き、UI には Auto-updates paused と表示されます。
ピン留めを解除するには: Resume auto-updates をクリックします。Devin は最新の成功したビルドに切り替わります。
Gitベースのブループリント
ブループリントは、.devin/blueprint.yaml ファイルとしてリポジトリ内に直接保存できます。変更をマージしたら、sync API を呼び出すか、UI で Sync をクリックしてブループリントを更新し、その後ビルドをトリガーします。これにより、アプリケーションコードで利用しているのと同じコードレビューのワークフローを使いながら、CI ステップで sync を自動化できます。
セットアップ手順と詳細については、Gitベースのブループリント を参照してください。
ビルドのトラブルシューティング
Initialize ステップが失敗しました
よくある原因: シェルコマンドのタイプミス、パッケージが利用できない、ネットワークのタイムアウト、GitHub Action の参照先の誤り。 対処法: ビルドログで正確なエラー内容を確認してください。ブループリント 内のinitialize を更新して保存してください。新しいビルドが自動的にトリガーされます。
リポジトリのクローンに失敗しました
主な原因: Devin がリポジトリにアクセスできない、リポジトリの名前が変更された／移動された／削除された、または一時的なネットワークの問題が発生した。 対処法: Git プロバイダーの設定でリポジトリへのアクセス権を確認してください。リポジトリ名が変更されていた場合は、いったん削除して再度追加してください。メンテナンス手順が失敗しました
一般的な原因: 依存関係の競合、必要なシステムライブラリの不足、ディスク容量不足、ロックファイルの不整合。 対処法: 失敗したパッケージまたはコマンドのログを確認してください。maintenance または initialize を更新して不足している依存関係をインストールするか、リポジトリ内のロックファイルを修正してください。
ビルドのタイムアウト
各ブループリントステップのタイムアウトは3時間です。リポジトリのクローンとプルにも、同じく3時間のタイムアウトがあります。よくある原因: 大規模なネイティブ依存関係をソースからコンパイルしている (ビルド済みバイナリを利用する) 、大容量のアーティファクトをダウンロードしている、入力待ちで処理が止まるコマンドを実行している (すべてのコマンドは非対話型である必要があります) 。修正を繰り返す
- ビルドログを確認して失敗の原因を特定する
- 該当するブループリントを更新する
- 保存する (新しいビルドが自動的にトリガーされます)
- 新しいビルドのログを確認する
- ビルドが成功するまで繰り返す
失敗したビルドの完了を待つ必要はありません。新しい設定を保存すると、キューに入っているビルドはキャンセルされ、新しいビルドが最初から開始されます。
次のステップ
Scenarios: growing with ACME Corp
実践的な使用例：1つのリポジトリから始めて、共有依存関係を持つ複数のリポジトリ、さらに複数の組織へと進みます。
差分ビルド
ブループリントが変更されたワークスペースだけを再ビルドして、ビルドを高速化します。
ブループリントでのGitHub Actions
シェルスクリプトを書かずに、GitHub Actionsを利用して言語、ツール、SDKをインストールできます。
ワークスペースとモノレポ
複数パッケージのリポジトリで使う、サブシェル、ワークスペースのスコープ、Knowledge エントリ。
ブループリントリファレンス
完全なフィールドリファレンス：step types、環境変数、シークレット、ファイル添付。
Template library
Python、Node.js、Go、Java、Ruby、Rust、高度なパターン向けの、コピーしてすぐ使えるブループリント。
Gitベースのブループリント
ブループリントをリポジトリ内の
.devin/blueprint.yaml として保存し、APIまたはUI経由で同期します。Enterprise環境管理
Enterprise全体の環境管理：3ティア階層、シークレット、組織横断の設定。