メインコンテンツへスキップ

​
はじめに

前提条件: 環境を設定する前に、Devin があなたのリポジトリにアクセスできる必要があります。Git 統合がまだ設定されていない場合は、設定手順について 開始前に を参照してください。Enterprise ユーザーは、Enterprise Settings > Repository Permissions で各 org に対応するリポジトリへのアクセスも付与する必要があります。
まだクラシック構成を利用していますか？ 宣言的構成にはいつでも移行できます。移行作業の大半は Devin に任せられます。宣言的構成への移行 を参照してください。
ほとんどのユーザーに最適です。Devin がプロジェクトを分析し、必要なツールや依存関係を判断して、ブループリントを生成します。あとは内容を確認して承認するだけです。
1

Devin セッションを開始する

新しいセッションを開き、Devin にリポジトリの設定を依頼します。たとえば、“この repo の環境を設定してください。“
2

確認して承認する

Devin がブループリントを提案します。タイムラインに suggestion cards が表示されるので、内容を確認して Approve をクリックしてください。
3

確認する

ビルドが完了したら、新しいセッションを開始します。Devin は、必要な設定がすべて事前に反映された新しいスナップショットから起動します。lint や test のコマンドを実行するよう Devin に依頼し、問題なく動作することを確認してみてください。
このガイドの残りの部分では、手動での進め方を詳しく説明します。推奨される方法を利用した場合でも、Devin が何を生成したのかを理解するうえで役立ちます。

​
仕組み

宣言的構成では、3 つの概念を使用します。
ConceptWhat it isAnalogy
Blueprintインストールする内容と Devin の環境の設定方法を記述した YAML 構成ファイルDockerfile
ビルドブループリント を実行し、repo をクローンして、スナップショット を生成するプロセスdocker build
Snapshotセッションの起動元となる、固定された起動可能な環境イメージDocker image
ブループリント は必要な内容を記述します。 これらはユーザーが作成し、Settings UI で編集します。 ビルド は ブループリント を実行して スナップショット を生成します。 ビルド は ブループリント を保存すると自動的に実行され、dependencies を最新の状態に保つために定期的 (約 24 時間ごと) にも実行されます。 スナップショット はセッションの起動元です。 各組織には 1 つのアクティブな スナップショット があります。すべてのセッションはクリーンなコピーから起動します。セッションでの changes は スナップショット には保持されません。

​
Blueprint のセクション

Blueprint には 3 つのセクションがあります。
セクション目的実行されるタイミング
initializeツール、ランタイム、システムパッケージをインストールビルド時のみ。結果はスナップショットに保存されます。
maintenanceプロジェクトの依存関係をインストール/更新し、認証情報の設定を書き込むビルド時 + 毎回のセッション開始時
knowledgeDevin 向けの参照情報 (lint、test、build コマンド)実行されません。セッション開始時に Devin の前提情報に読み込まれます。
initialize は、一度だけ実行すればよい処理のためのセクションです。たとえば、言語ランタイム、システムパッケージ、グローバル CLI ツールなどです。 maintenance は、常に最新の状態に保つ必要がある依存関係のインストール向けです。ビルド時に実行され、さらに最新コードを pull した後のセッション開始時にも再度実行されるため、コマンドは高速で増分的なものにしてください (npm ci ではなく npm install を利用する) 。 knowledge は参照情報であり、実行はされません。ここで、lint、test、build の正しいコマンドを Devin に伝えます。項目は簡潔に保ち、実行可能なコマンドに絞ってください。
ここでの Knowledge と Knowledge プロダクト機能の違い: blueprint 内の knowledge セクションは、環境に紐づいた短いコマンド参照のためのものです。アーキテクチャドキュメント、慣例、チームの ワークフローには、代わりに独立した Knowledge 機能を利用してください。
完全なフィールド仕様 (step types、GitHub Actions のサポート、環境変数、secrets、ファイル添付) については、Blueprint reference を参照してください。

​
ブループリント の適用範囲

ブループリント は次の 2 つのレベルで定義できます。
LevelWhere to configureWhat to put here
組織Settings > Environment configuration > Org-wide setupすべてのリポジトリで共有するツール: 言語ランタイム、パッケージマネージャー、Docker 認証
リポジトリSettings > Environment configuration > [repo name]プロジェクト固有のセットアップ: npm install、lint/test/build コマンド
ブループリント は追加式です。リポジトリの ブループリント は、組織の ブループリント を基盤としてその上に追加されます。リポジトリの maintenance では、組織の initialize でインストールされたツールを利用できます。特定のツールが 1 つのリポジトリでのみ必要な場合は、そのリポジトリの ブループリント に追加してください。すべてのリポジトリで必要な場合は、組織の ブループリント に追加してください。
Enterprise ユーザー: 3 つ目の階層として、すべての組織に適用される Enterprise ブループリント があります。詳しくは Enterprise environment overview を参照してください。

​
ビルドとセッション

​
スナップショット

組織には1つのアクティブなスナップショットがあります。これは、ツール、リポジトリ、依存関係があらかじめインストールされた VM イメージです。設定されたすべてのリポジトリは、この単一のイメージ内にクローンされ、セットアップされます。各セッションはクリーンなコピーから起動します。

​
ビルドの仕組み

ビルドは、ブループリントを順番に実行して新しいスナップショットを作成します。 
1. Enterprise blueprint, if configured (runs in ~):
   a. initialize
   b. maintenance
2. Org blueprint (runs in ~):
   a. initialize
   b. maintenance
3. Clone all repositories (up to 10 concurrent)
4. For each configured repo, in the order shown in Settings
   (runs in ~/repos/<repo-name>):
   a. initialize
   b. maintenance
5. Health check, then snapshot is saved
レイヤーは追加式です。repo 固有のコマンドでは、org または Enterprise ブループリント でインストールされたツールを利用できます。下位レベルで、上位レベルの設定を上書きすることはできません。ビルドには通常 5～15 分かかります。各ステップは 1 時間でタイムアウトします。

​
セッションの仕組み

各セッションは、スナップショットのクリーンなコピーで起動します。セッションが終了すると、すべての変更は破棄されます。セッション開始時には、次の処理が行われます。
  1. Enterprise と組織全体の maintenance が ~ で実行されます。
  2. 対象のリポジトリの最新コードが取得されます。
  3. 前回のビルド以降の依存関係の変更を反映するため、そのリポジトリの maintenance が再度実行されます。
  4. そのリポジトリの knowledge エントリが Devin の前提情報に読み込まれます。
Knowledge はリポジトリ単位です。 5 つのリポジトリを設定している場合、Devin が参照できるのは現在作業中のリポジトリの Knowledge エントリだけです。

​
ビルドがトリガーされる条件

トリガー説明
ブループリントの保存ブループリントの作成、更新、または削除
リポジトリの追加または削除リポジトリ一覧への変更
リポジトリシークレットの追加新しいシークレットを利用できるようにするには再ビルドが必要
手動でのトリガーUI で Build または Rebuild をクリック
定期的な更新自動。おおむね 24 時間ごと
Devin からの提案Devin がセッション中にブループリントの変更を提案
一度に実行できるビルドは 1 つだけです。新しいトリガーが発生すると、キューに入っているビルドはキャンセルされ、新しいビルドが最初から開始されます。

​
ビルドステータス

ステータス意味
成功すべてのステップが完了しました。スナップショットの準備ができています。
部分的リポジトリ単位の一部のステップは失敗しましたが、スナップショットは利用可能です。成功したリポジトリは通常どおり動作し、失敗したリポジトリではブループリントの修正が必要です。
失敗重大な障害です (org または Enterprise のセットアップに失敗しました) 。スナップショットは利用できません。
キャンセル済みより新しいビルドに置き換えられたか、手動でキャンセルされました。
部分的なビルドでも、動作するスナップショットが生成されます。5 つのリポジトリのうち 1 つでブループリントに問題があっても、残り 4 つは完全に機能します。
ビルドが失敗している場合は、ビルドのトラブルシューティングで段階的なデバッグガイドを確認してください。

​
環境の管理

​
リポジトリの状態

リポジトリは、Environment の設定画面で次の 3 つの状態で表示されます。
StateMeaning
Configuredinitialize/maintenance/knowledge を含む ブループリント があります。スナップショット 内で完全にセットアップされています。
Includedスナップショット にクローンされていますが、カスタム ブループリント はありません。Devin はコードにアクセスできます。
Availableorg には接続されていますが、Environment には追加されていません。クローンもされていません。
Included と Configured の違い: 「Included」のリポジトリはクローンされているため Devin はコードにアクセスできますが、カスタムのセットアップコマンドはありません。一方、「Configured」のリポジトリには、initialize/maintenance/knowledge の instructions が明示的に設定されています。

​
シークレット

$VARIABLE_NAME 構文でシークレットを参照します。追加するには、設定 > シークレット を開きます。 
maintenance:
  - name: Configure private registry
    run: npm config set //registry.npmjs.org/:_authToken $NPM_TOKEN
シークレットは、ビルド中およびセッション中に環境変数として利用できます。これらはスナップショットが保存される前に削除されますが、initialize 中にコマンドがシークレットの値を設定ファイルに書き込んだ場合、その値はスナップショットに残ります。認証情報は必ず maintenance 中に書き込んでください。 シークレットのスコープと挙動の詳細については、ブループリント reference を参照してください.

​
複数のリポジトリ

各リポジトリにはそれぞれ専用のブループリントが割り当てられます。ビルド中は、すべてのリポジトリが同じスナップショット内でセットアップされ、別々のディレクトリにクローンされ、依存関係もそれぞれ個別にインストールされます。 2つのリポジトリがグローバルツールの異なるバージョンをインストールしたり、共有ファイル (~/.bashrc など) を変更したりすると、最後に実行されたものが反映されます。競合を避けるには、共有ツールのインストールを org-wide ブループリントにまとめてください。

​
モノレポ

モノレポでは、すべてのサブプロジェクトを対象とする単一のブループリントを作成します。サブディレクトリでコマンドを実行するには、サブシェルを使用します。 
maintenance:
  - name: Frontend deps
    run: (cd packages/frontend && pnpm install)
  - name: Backend deps
    run: (cd packages/backend && uv sync)
丸括弧 (cd ... && ...) はサブシェル内で実行されるため、次のステップでは作業ディレクトリが元に戻ります。

​
ピン留めと自動更新

デフォルトでは、Devin は最新の成功したビルドのスナップショットを利用します。ピン留めを使うと、特定のビルドのスナップショットに固定できます。これは、新しいビルドで不具合が発生した場合や、一連のセッションで環境を固定したい場合に便利です。 ピン留めするには: Snapshot build history に移動し、対象のビルド (success または partial で、7 日以内のもの) を見つけて、Pin をクリックします。ピン留め中は定期的な更新がスキップされ、UI には Auto-updates paused と表示されます。 ピン留めを解除するには: Resume auto-updates をクリックします。Devin は最新の成功したビルドに切り替わります。

​
Gitベースのブループリント

Gitベースのブループリントは現在サポートされていません。この機能は近日提供予定です。今後は、ブループリントをリポジトリに保存し、変更時にビルドが自動的にトリガーされるようになります。現時点では、 UI でブループリントを設定してください。

​
ビルドのトラブルシューティング

​
Initialize ステップが失敗しました

よくある原因: シェルコマンドのタイプミス、パッケージが利用できない、ネットワークのタイムアウト、GitHub Action の参照先の誤り。 対処法: ビルドログで正確なエラー内容を確認してください。ブループリント 内の initialize を更新して保存してください。新しいビルドが自動的にトリガーされます。

​
リポジトリのクローンに失敗しました

主な原因: Devin がリポジトリにアクセスできない、リポジトリの名前が変更された／移動された／削除された、一時的なネットワークの問題。 対処法: Git プロバイダーの設定でリポジトリへのアクセス権を確認してください。リポジトリ名が変更されていた場合は、いったん削除して再度追加してください。

​
メンテナンス手順が失敗しました

一般的な原因: 依存関係の競合、必要なシステムライブラリの不足、ディスク容量不足、ロックファイルの不整合。 対処法: 失敗したパッケージまたはコマンドのログを確認してください。maintenance または initialize を更新して不足している依存関係をインストールするか、リポジトリ内のロックファイルを修正してください。

​
ビルドのタイムアウト

各ステップのタイムアウトは1時間です。よくある原因: 大規模なネイティブ依存関係をソースからコンパイルしている (ビルド済みバイナリを利用する) 、大容量のアーティファクトをダウンロードしている、入力待ちで処理が止まるコマンドを実行している (すべてのコマンドは非対話型である必要があります) 。

​
修正を繰り返す

  1. ビルドログを確認して失敗の原因を特定する
  2. 該当するブループリントを更新する
  3. 保存する (新しいビルドが自動的にトリガーされます)
  4. 新しいビルドのログを確認する
  5. ビルドが成功するまで繰り返す
失敗したビルドの完了を待つ必要はありません。新しい設定を保存すると、キューに入っているビルドはキャンセルされ、新しいビルドが最初から開始されます。

​
次のステップ

ブループリントリファレンス

完全なフィールドリファレンス：ステップの種類、GitHub Actions、環境変数、シークレット、ファイル添付。

テンプレートライブラリ

Python、Node.js、Go、Java、Ruby、Rust、高度なパターン向けの、コピーしてすぐ使えるブループリント。

従来のセットアップからの移行

対話型ウィザードから宣言的なブループリントへ移行するための手順ガイド。

Enterprise環境管理

Enterprise全体の環境管理：3層階層、シークレット、組織横断の設定。