Skip to main content

​
なぜ Devin を GitHub と統合するのか？

GitHub の組織に Devin を統合すると、Devin はプルリクエストを作成し、PR コメントに返信し、リポジトリ内で直接コラボレーションできるようになります。これにより、Devin をエンジニアリングチームのフルメンバーとして活用できます。 まずは app.devin.ai にアクセスし、Settings > Integrations > GitHub を開き、Add Connection をクリックして、表示される手順に従ってください。Devin にアクセスさせるリポジトリを選択し、必要な権限を確認します。
GitHub Enterprise Server または Data Residency 対応の GitHub Enterprise Cloud を利用していますか？ セットアップ手順については、GitHub Enterprise Server 統合ガイド を参照してください。

​
インテグレーションの設定

Devin インテグレーションを作成および管理するには、GitHub 組織の管理者である必要があります。問題がある場合は、Common Issues を参照してください。
  1. app.devin.ai の Devin アカウントで Settings > Integrations > GitHub を開き、Add Connection をクリックします。
Devin
  1. まだ GitHub にログインしていない場合は、認証を求められます。
Devin
  1. Devin と接続したい GitHub 組織を選択します。
Devin
  1. Devin に付与するアクセス範囲として All repositories か Select repositories を選択し、Devin がアクセスできるリポジトリを制御します。
Devin
  1. GitHub の認可が完了すると、Devin の設定画面にリダイレクトされるので、インテグレーションが有効になっていることを確認します。
Devin
Devin が変更をマージする前に、必要なチェックがすべて通過していることを確実にするため、メインブランチにブランチ保護ルールを有効にすることを推奨します。

​
GitHub 連携で Devin を使う

​
Core および Teams ユーザー向け

インテグレーションの設定が完了すると、Devin の Web アプリケーション内で、プロンプト中にリポジトリを @メンションして参照できるようになります。

​
Enterprise ユーザー向け

統合の設定が完了したら、Enterprise Settings > Repository Permissions から、特定の組織にリポジトリを割り当てることができます。
Devin
リポジトリを初めて利用する場合は、Devin がコードベースに関する正確で 最新の情報を取得できるように、オンボーディングフローでの開発環境セットアップ を完了することをおすすめします。セッションがアーカイブされていない限り、Devin は PR のコメントに自動で返信します。

​
GitHub での Devin の権限管理

セットアップ時に、Devin に組織内の すべてのリポジトリ へのアクセスを許可するか、特定のリポジトリ へのアクセスに制限するかを選択できます。 リポジトリアクセスは、GitHub の設定からいつでも変更できます:
  1. GitHub 組織の Settings > GitHub Apps に移動します (例: https://github.com/organizations/<org_name>/settings/installations)
  2. Devin.ai Integration の Configure をクリックします
  3. Repository access のセクションで、すべてのリポジトリへのアクセスを許可するか、特定のリポジトリを選択します
  4. Save をクリックして変更を反映します
Devin
Devin には以下の権限が必要です: Read アクセス: Read および write アクセス: これらの権限により、Devin は通常のコントリビューターと同様にリポジトリで作業でき、ブランチの push、pull request の作成、PR でのディスカッションへの参加が可能になります。

​
プルリクエストテンプレート

Devin がプルリクエストを作成する際、リポジトリ内のテンプレートを利用して PR の説明文を構造化します。テンプレートを用意しておくと、Devin はそのフォーマットに従って GitHub に PR を送信します。 以下の対応している PULL_REQUEST_TEMPLATE のいずれかの場所に devin_pr_template.md という名前のファイルを追加することで、既存の人間向けデフォルトテンプレートを変更せずに、Devin 専用のテンプレートを用意できます。レビュアー用チェックリストや変更ファイルの Mermaid 図など、追加のコンテキストを Devin に渡したい場合に便利です。

​
テンプレートの検索順序

Devin は、次の順序でテンプレートを検索し、最初に見つかったものを使用します。
  1. PULL_REQUEST_TEMPLATE/devin_pr_template.md
  2. docs/PULL_REQUEST_TEMPLATE/devin_pr_template.md
  3. .github/PULL_REQUEST_TEMPLATE/devin_pr_template.md
  4. pull_request_template.md
  5. docs/pull_request_template.md
  6. .github/pull_request_template.md
テンプレートが見つからない場合、Devin はデフォルトの PR 説明形式を使用します。
既存の pull_request_template.md を Devin に使わせたい場合は、そのファイルを上記のいずれかの devin_pr_template.md パスにコピー (またはシンボリックリンクを作成) してください。
GitHub のプルリクエストテンプレート (サポートされる配置場所、複数テンプレート、クエリパラメータなど) について詳しくは、GitHub Docs の Creating a pull request template for your repository を参照してください。

​
コミット署名

Devin のコミットに GPG 署名を付けるには、キーがセッションをまたいで保持されるように、environment で設定します。セッションのターミナル内でキーを生成しても機能しません。Devin の各セッションは machine image のクリーンなコピーから起動するため、セッション中に作成したキーはセッション終了時に破棄されます。
environment 設定による GPG 署名で Verified コミットになるのは、 Devin が commit author の場合だけです。GitHub は署名を author の identity に対して検証しますが、author がリクエストした user になる Commit authoring モード (例: “Co-authored”, “User only”, “User as author, Devin as committer”) では、Devin はセッションごとに user.email を各 user 自身の email で上書きします。そのため、単一の共有 GPG キーとは一致しません。この設定を利用する前に、 org の Commit authoring モードを “Devin only” または “Devin as author, user as committer” に設定してください。
すべての repo で署名付きコミットの設定が適用されるよう、これを org-wide レイヤー (すべての orgs で必要な場合は enterprise レイヤー) で設定します。
  1. commit author の identity と、Devin が push に利用する認証情報の両方を持つ、専用の GitHub user account を作成するか、既存のものを選択します。例: devin@company.com。両方を 1 つの account にまとめると署名設定はシンプルになります。2 つの account に分ける場合は、以下の設定も両方にまたがって必要になります。
  2. GitHub の instructions に従い、その account の email を UID として、ローカルで GPG キーを生成します。
  3. 公開 キーを、GPG UID と一致する verified email を持つ GitHub account の GitHub Settings > SSH and GPG keys に upload します。GitHub は、push に利用した identity ではなく、commit author の identity に対して署名を検証します。そのため、公開キーは user.email の email を所有する account に登録されている必要があります。 (push にも同じ専用 account を利用している場合、この作業は 1 回だけで済みます。)
  4. 非公開 キーを export して base64 エンコードし、対応する GIT_USER_NAME / GIT_USER_EMAIL とあわせて、Settings > Secrets に secrets として追加します。
  5. org-wide environment config でキーを import し、各セッションの開始時に署名を有効にします。完全な YAML については、コピー＆ペーストで使える GPG commit signing example を参照してください。
committer の email (user.email) は GPG キー上の UID と一致している必要があり、 さらに同じ email が、公開キーを upload した GitHub account 上で verified email になっている必要があります。この 3 つのいずれかが一致しない場合、 署名自体が有効でも、GitHub ではその commit は Unverified と表示されます。

​
セキュリティに関する考慮事項

  • ブランチ保護: Devin が変更をマージする前に、すべての必須チェックが通っていることを確保するため、メインブランチにブランチ保護ルールを有効にすることを推奨します。
  • 組織レベルの権限: Devin は、セッションを実行している個々のユーザーの権限ではなく、組織レベルで付与された権限を使用します。
  • 一貫したアクセス: GitHub の組織と Devin の組織の両方にアクセス権限を持つすべてのユーザーは、同じ Devin 連携の権限を共有します。
  • リポジトリ作成: Devin は、GitHub アカウント内で新しいリポジトリを作成することはできません。

​
IP Allowlisting

組織で GitHub へのアクセスに IP 許可リストを設定している場合は、次の IP アドレスを追加してください。
  • 100.20.50.251
  • 44.238.19.62
  • 52.10.84.81
  • 52.183.72.253
  • 20.172.46.235
  • 52.159.232.99
  • 4.204.199.103
  • 54.201.200.193
  • 54.69.238.189
  • 100.23.34.160
これらの IP アドレスは今後のアップデートで変更される可能性があります。変更があった場合に備えて、リリースノートを確認することを推奨します。

​
トラブルシューティング: GitHub 組織が誤った Devin 組織に接続されている

GitHub 組織が、アクセス権のない Devin 組織にすでに接続されている場合、GitHub 組織の管理者は既存のインストールを削除し、別の Devin 組織に再インストールできます。
インストールを削除する前に、現在の Devin 組織の所有者に確認することを推奨します。
  1. github.com/settings/installations に移動し、Devin.ai Integration の横にある Configure をクリックします。 必要に応じて、右上の Go to settings page ドロップダウンを使用して、正しい GitHub 組織に切り替えます。
    GitHub 設定の組織を切り替える
  2. インストール ページで、Danger zone セクションまでスクロールし、Uninstall をクリックして GitHub 組織から Devin.ai Integration を削除します。
    Devin.ai Integration をアンインストールする
  3. app.devin.ai に戻ってページを更新します。これで、GitHub 統合を自分の Devin 組織に再インストールできます。

​
GitHub 統合に関するよくある質問

はい。Devin の組織には、GitHub Organization または個人の GitHub アカウントのいずれも接続できます。ただし、Devin がチームで必要とするリポジトリへアクセスできるよう、適切な権限を持つアカウントを接続することを推奨します。
GitHub 統合をインストールした組織のメンバーであるユーザーだけが、自分の Devin セッションでその統合を利用できます。Devin が利用できる GitHub 統合のアクセス権は、ユーザーの所属組織のメンバーシップに基づいて引き継がれます。
暗号鍵は AWS KMS によって管理され、定期的にローテーションされます。