pull requestの横で、いくつのタブが開いていますか？
製品の無料トライアルのオンボーディングフローで、新たなissueに取り組んでいるとします。「invite your teammates」のステップを任意にするというものです。登録者が増えるにつれ、サポートチームはこのステップを摩擦点として指摘し続けています。すぐに成果を出せる施策ですよね？
スコープの策定からdeploymentまで、次の4つの質問への回答が必要です。
これは本当に正しい変更ですか？
自分が触れる依存関係はクリーンですか？
これを安全にリリースするにはどうすればよいですか？
今、deploymentを安全に実行できますか？
それぞれの回答は異なるツールにあるため、pull requestで作業するということは、同じコンテキストを4つの異なる場所の間で持ち運ぶことを意味します。
GitHub agentアプリケーションは、これらの質問に答えるために必要なツールを、すでに作業している場所に持ち込みます。しかも、自社のCopilot cloud agentと同じプラットフォームおよびharness上で実行します。
以下の例では、GitHubから一度も離れることなくこれらの質問に答え、この依頼を完了するために、Amplitude、Endor Labs、LaunchDarkly、PagerDutyといった、すでに依存しているサービスをどのように利用できるかを示します。
1. 開発を始める前に
サポートチームは、「invite your teammates」のステップが、製品のオンボーディングプロセスに入る顧客にとって煩わしいと話しています。しかし、誰が不満を訴えているのか、またその不満が顧客離れにつながっているのかについては、何の情報も提供していません。疑ってかかるのは適切です。そこで、Amplitudeを開いて推測を検証するクエリを作成する代わりに、直接AgentsタブからAmplitude agentに尋ねます。
@amplitude[agent] チーム招待ステップの完了は、ファネルの後続段階での成功と関連していますか？測定しているセグメント別に分けてください。
違いは明確です。このステップを完了したチームユーザーは、その後も継続利用する可能性が高い一方、ソロユーザーにはそのような関連はありません。これでスコープを見直す根拠が得られました。ソロで登録したユーザーにはこのステップを後回しにし、チームには残してください。
製品インサイトにアクセスできる場所がGitHub内になったため、コードを書く前に方針を修正できます。
2. 開発中
Copilotが変更用のドラフトpull requestを作成しています。アプリケーションは、オンボーディングフローで使用される依存関係も更新します。後でCIスキャンが失敗するのを待つ代わりに、コメントでEndor Labs agentに尋ねます。
@endor-labs-github-agenthq[agent] このpull requestが変更した依存関係について、注意すべき点はありますか？
Agentは変更された依存関係を特定し、既知のセキュリティ脆弱性とパッケージに関するより広範なリスクを確認したうえで、pull requestに報告します。今回はすべて問題なさそうです。対処すべきことは何もありません。
依存関係のレビューが、変更がまだ目の前にある段階でのプロアクティブなチェックになります。CIスキャンが失敗してから修正するよりも、はるかに優れています。
3. リリース
先ほどの発見が、実装に反映されます。ソロで登録したユーザーは任意のパスを利用し、チームは既存のパスを維持します。これらのセグメントは登録時に判定されるため、feature flagで直接ターゲットにできます。チームメイトに頼むように、LaunchDarkly agentにこれを設定してもらいます。
@launchdarkly-agent[agent] このpull request用のfeature flagを作成し、コードに接続してください。
– key: defer-team-invite
– type: boolean
– default: false
– target: solo-intent signups
– rollout: internal > 5% > 25% > 100%
AgentはLaunchDarkly上でフラグを作成し、コードへの実装を確認できるよう、コミットとして追加します。対象環境で承認が必要な場合は、ターゲティングの変更を直接適用する代わりに、承認リクエストを作成します。リリースを進めるかどうかは、引き続き人が判断します。
フラグの設定は、別のツールや手動でのコード移行、Slackでの調整を必要とするプロセスではなくなり、1つのpull requestコメントと、レビュー用のコミットになります。
4. リリース前
レビューによってコードが正しいことは確認できますが、サービスがデプロイに適した状態にあるかどうかは別の問題です。