この記事では、組織のメンバーが Devin セッションを実行する方法について説明します。
Devin は、タスクの実行を通じて組織を支援します。効果を最大化するには、まずは小さなタスクから始め、ジュニアエンジニアに指示するのと同じように、具体的で詳細な指示を与えてください。
エンタープライズは複数の組織で構成されており、それぞれが特定のリポジトリへのアクセスを必要とします。
アクセスが必要な各組織ごとに、リポジトリをインストールする必要があります。リポジトリをインストールすると、Devin のワークスペースがタスクを完了できるようになります。これは、Devin がコードのビルド、lint、テストを適切に実行できるように構成されるためです。
Devin を使用する前に、各組織のメンバーが次のセットアップを完了する必要があります。
オンボーディング ステップ 1 - Git の接続
オンボーディング ステップ 2 - Slack の接続
エンタープライズで Slack を使用していない場合は、Web アプリを使用します。
オンボーディング ステップ 3 - リポジトリの選択
オンボーディング ステップ 4 - Devin のワークスペースのセットアップ
オンボーディング ステップ 5 - リポジトリ依存関係のセットアップ
たとえば、apt-get {your-package} のようなコマンドです。
オンボーディング ステップ 6 - lint のセットアップ
たとえば、npm run lint のようなコマンドです。
オンボーディング ステップ 7 - テストのセットアップ
たとえば、npm run test のようなコマンドです。
オンボーディング ステップ 8 - セットアップの完了
Devinセッションは互いに分離されており、同時に実行中のメンバーセッション同士が影響し合うことはありません。
ユーザー数と平均サインアップ年齢を含む JSON オブジェクトを返す、新しいエンドポイント /users/stats を作成してください。
既存の PostgreSQL の users テーブルを使用してください。
レスポンス構造については、statsController.js の /orders/stats エンドポイントを参照してください。
新しいエンドポイントが StatsController.test.js スイートでカバーされていることを確認してください。
UserProfileComponent に、ユーザー権限（admin, editor, viewer）の一覧を表示するドロップダウンを追加してください。
スタイリングは DropdownBase を利用してください。
ロールが選択されたら、既存の API を呼び出してユーザー権限を設定してください。
選択内容に応じて DB 上のユーザー権限が更新されることを確認して検証してください。適切なテスト方法については、あなたの Knowledge を参照してください。
AuthService のメソッド `login` と `logout` に対する Jest テストを追加してください。
これら 2 つの関数のテストカバレッジが少なくとも 80% になるようにしてください。
`UserService.test.js` をサンプルとして参照してください。
実装後に `npm test -- --coverage` を実行し、両方の関数についてカバレッジレポートが 80% 超になっていることを確認してください。
また、有効な認証情報と無効な認証情報の両方でテストが通ること、さらに `logout` がセッションデータを正しくクリアしていることも確認してください。
or refactoring existing code
logger.js を JavaScript から TypeScript に移行してください。
すでに `tsconfig.json` と、検証用の `LoggerTest.test.js` テストスイートがあります。
エラーなくコンパイルできることを確認し、既存の設定は変更しないでください！
移行後は、次の手順で検証してください：
1) `tsc` を実行し、型エラーがないことを確認する
2) `npm test LoggerTest.test.js` でテストスイートを実行し、すべてのテストがパスすることを確認する
3) コードベース全体で、既存の logger メソッド呼び出しが型エラーなしに引き続き動作していることを確認する
pg から Sequelize への移行を行っています（https://sequelize.org/api/v6/identifiers を参照してください）。
UserModel のクエリを、Sequelize のメソッドを使うように更新してください。
このコードベースでの実装例については、OrderModel を参照してください。
実装後は、次の手順で検証してください:
1) `npm run test:integration UserModel.test.js` を実行し、すべてのインテグレーションテストが成功することを確認する
2) ユーザー 1000 件分のテストデータセットで実行時間を確認し、クエリパフォーマンスが低下していないことを確認する
3) `npm run test:e2e user-flows.test.js` を実行し、すべての CRUD 操作が引き続きデータ整合性を維持していることを検証する
素早く PR を作成する（このプロンプトは Playbook での使用を推奨します）
## Overview
このタスクでは、リポジトリに対して迅速に pull request を作成します。
これは「quick」PR なので、コードを実行したりテストしたりする必要はありません。PR を作成するだけでよく、テストはユーザーが行います。あなたの責任はコードの読み書きのみです。
## What's Needed From User
- pull request を作成する対象のリポジトリ
## Procedure
### ワークスペースを準備する
1. 自分のマシン上で対象のリポジトリに移動します（分からない場合はユーザーに確認してください）。
- main ブランチをチェックアウトし、main ブランチの名前を確認して控えておきます。
- pull request を作成するので、新しいブランチを作成してチェックアウトします。ブランチ名は `devin/<your-branch-name>/X` 形式にする必要があります。ここで X はランダムな数字です。例: `devin/fix-popup/3234`。`git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` を実行し、`{branch-name}` を作成したいブランチ名に置き換えてください。
2. リクエスト内容とコードベースを確認し、変更内容を計画します。
- 最も関連性の高いファイルやコード部分を確認し、関連するスニペットを特定します。
- 自分の計画をユーザーに伝えます。
### PR 本体の作業
3. コードを変更します。
- ユーザーから明示的に依頼されていないことは変更しないでください。
4. PR を作成します。
- 変更をコミットしてプッシュし、ユーザーに伝えます。
- PR を作成するための正確なコマンドは、アドバイスのセクションを参照してください。
- pull request を作成し、見た目に問題がないか自分で確認します。
- すべての GitHub Actions が正常に完了していることを確認し、失敗した場合は通るまで必要な修正を行います。
- PR リンクをユーザーに送り、実施した変更内容を要約します。
5. レビューからのフィードバックに対応し、変更を行うたびに PR リンクを再度送ります。
- 更新が必要になった場合は、同じブランチにコミットを追加でプッシュしてください。新しいブランチは作成しないでください。
## Task Specification
- ユーザーへのメッセージに PR リンクを含めること
- PR 作成後に、自分で PR をレビューしていること
- PR に不要な差分が含まれていないこと
- PR で、ユーザーから明示的に依頼されていない変更を行っていないこと
- PR の説明には、チェックリスト形式で変更内容の要約を含めること
- PR の説明には、コードがテストされていない状態で書かれたことを明記し、`- [ ] Test the changes` という項目を含めること
- PR の説明には、ユーザーが提供したメタデータ（例: 適切な構文での linear のチケットタグ）を含めること
- PR の説明が不正なフォーマットになっていないこと（改行が乱れる場合は `--body` ではなく `--body-file` を使用してください）
## Forbidden Actions
- ブラウザから github.com にアクセスしようとしないでください。認証されていません。
- ブランチに対して絶対に force push しないでください！作業を失わないように、rebase ではなく merge を優先してください。
- main ブランチに直接プッシュしないでください。
## Advice and Pointers
- main ブランチ名（`main` または `master` など）を `git branch` で必ず再確認してください。
- GitHub Actions で CI/CD が有効なリポジトリでは、`gh` CLI を使ってビルドログを確認できます。ビルド修正や lint 修正を依頼された場合は、まず直近のビルドログを見るところから始めてください。
- ファイルをコミットまたは追加する前に `git status` を確認してください。
- コミット前に、自分が行った変更を確認するために `git diff` を使用してください。
- 既存のリポジトリを更新している場合は、pull request の作成に `gh` CLI を使用してください。
- 更新を行うたびに PR リンクをユーザーに送り、再レビューを依頼して、ユーザーにとって分かりやすくなるようにしてください。
- ユーザーから教えてもらった任意のリポジトリには、すでにアクセス権限が付与されているはずです。そうでない場合は、ユーザーにアクセス権を依頼してください。
