速遞｜如何通過(guò) Agent Apps 將軟件交付工作流引入 GitHub)
作者Sam Zhang排版Alan Wang了解 GitHub 中的四款 Agent App 如何幫助你在整個(gè)軟件開(kāi)發(fā)生命周期SDLC中完成需求范圍界定、安全保障、逐步發(fā)布和功能交付并且全程無(wú)需離開(kāi) GitHub。你在 Pull Request 旁邊還打開(kāi)了多少個(gè)標(biāo)簽頁(yè)想象一下你正在處理產(chǎn)品免費(fèi)試用引導(dǎo)流程中的一個(gè)新 Issue將“邀請(qǐng)你的團(tuán)隊(duì)成員”這一步設(shè)為可選。隨著注冊(cè)量不斷增加支持團(tuán)隊(duì)一直反饋這一步會(huì)給用戶帶來(lái)阻礙?？雌饋?lái)是個(gè)很容易解決的問(wèn)題對(duì)吧但從需求范圍界定到部署你需要回答以下四個(gè)問(wèn)題這真的是正確的修改方向嗎我正在修改的依賴項(xiàng)是否安全可靠如何安全地逐步發(fā)布現(xiàn)在適合進(jìn)行部署嗎每個(gè)問(wèn)題的答案都來(lái)自不同的工具因此處理這個(gè) Pull Request 時(shí)你需要在四個(gè)不同的地方之間不斷傳遞相同的上下文。GitHub Agent Apps 將回答這些問(wèn)題所需的工具帶到了你已經(jīng)工作的地方并使用與 GitHub 自身 Copilot Cloud Agent 相同的平臺(tái)和運(yùn)行框架。下面的示例演示了如何使用你已經(jīng)依賴的服務(wù)例如 Amplitude、Endor Labs、LaunchDarkly 和 PagerDuty在完全不離開(kāi) GitHub 的情況下回答這些問(wèn)題并完成這項(xiàng)需求。開(kāi)始開(kāi)發(fā)之前支持團(tuán)隊(duì)表示對(duì)于正在使用產(chǎn)品進(jìn)行引導(dǎo)的客戶來(lái)說(shuō)“邀請(qǐng)你的團(tuán)隊(duì)成員”這一步很令人困擾但他們并沒(méi)有提供具體信息說(shuō)明究竟是誰(shuí)提出了投訴也沒(méi)有說(shuō)明這些投訴是否會(huì)導(dǎo)致用戶流失。對(duì)此保持懷疑是合理的。因此與其打開(kāi) Amplitude 并創(chuàng)建查詢來(lái)驗(yàn)證自己的判斷不如直接在 Agents 選項(xiàng)卡中向 AmplitudeAgent提問(wèn)Ampamplitude[agent] is completing the team invite step correlated with success later in the funnel? Break it down by segments were measuring.分析結(jié)果非常明確完成這一步的團(tuán)隊(duì)用戶后續(xù)留存的可能性更高而對(duì)于個(gè)人用戶則不存在這種相關(guān)性。因此重新界定需求范圍是合理的對(duì)于個(gè)人用戶的注冊(cè)流程可以將這一步延后而對(duì)于團(tuán)隊(duì)用戶則繼續(xù)保留現(xiàn)有流程?，F(xiàn)在你無(wú)需編寫任何代碼就可以直接在 GitHub 中獲取產(chǎn)品數(shù)據(jù)和洞察從而及時(shí)調(diào)整方向。開(kāi)發(fā)過(guò)程中Copilot 會(huì)針對(duì)這項(xiàng)修改創(chuàng)建一個(gè) Draft Pull Request。與此同時(shí)實(shí)現(xiàn)過(guò)程中還需要更新免費(fèi)試用引導(dǎo)流程所使用的依賴項(xiàng)。與其等到 CI 掃描失敗后再處理不如直接在評(píng)論中詢問(wèn) Endor Labs Agentendorendor-labs-github-agenthq[agent] is there anything I need to watch out for in the dependencies being touched by this pull request?該 Agent 會(huì)識(shí)別發(fā)生變更的依賴項(xiàng)檢查它們是否存在已知漏洞以及更廣泛的軟件包風(fēng)險(xiǎn)然后直接在 Pull Request 中返回分析結(jié)果。這一次一切看起來(lái)都很干凈沒(méi)有需要修復(fù)的問(wèn)題。依賴項(xiàng)審查因此成為修改仍處于當(dāng)前 Pull Request 階段時(shí)的一項(xiàng)主動(dòng)檢查而不是等 CI 掃描失敗后再進(jìn)行修復(fù)。顯然這種方式更加高效。發(fā)布過(guò)程中前面的分析結(jié)果現(xiàn)在會(huì)進(jìn)一步落實(shí)到實(shí)現(xiàn)中個(gè)人用戶注冊(cè)時(shí)進(jìn)入可選路徑而團(tuán)隊(duì)用戶繼續(xù)使用現(xiàn)有流程。由于這些用戶群體在注冊(cè)時(shí)就已經(jīng)確定因此可以直接通過(guò) Feature Flag 針對(duì)不同用戶群體進(jìn)行控制。你可以像向團(tuán)隊(duì)成員分配任務(wù)一樣請(qǐng) LaunchDarkly Agent 幫你完成設(shè)置darklylaunchdarkly-agent[agent] please create a feature flag for this pull request and wire it into the code. - key: defer-team-invite - type: boolean - default: false - target: solo-intent signups - rollout: internal 5% 25% 100%Agent 會(huì)在 LaunchDarkly 中創(chuàng)建 Feature Flag并將代碼實(shí)現(xiàn)作為一個(gè) Commit 添加到 Pull Request 中供你審核。如果目標(biāo)環(huán)境要求審批它會(huì)創(chuàng)建審批請(qǐng)求而不是直接應(yīng)用用戶定向配置。是否繼續(xù)推進(jìn)發(fā)布仍然由人來(lái)決定。Feature Flag 的配置流程因此從“切換到另一個(gè)工具、手動(dòng)交接代碼、再通過(guò) Slack 協(xié)調(diào)”變成一條 Pull Request 評(píng)論加一個(gè)供你審核的 Commit。發(fā)布之前代碼審查可以告訴你代碼本身是否正確但服務(wù)當(dāng)前是否處于適合部署的狀態(tài)則是另一個(gè)問(wèn)題。在合并之前你可以詢問(wèn) PagerDuty Agentpagerdutypagerduty-agent-app[agent] assess the deployment risk for this pull request against the onboarding service. Check active incidents and recent incident history, then recommend whether to proceed.Agent 會(huì)將代碼倉(cāng)庫(kù)映射到對(duì)應(yīng)的 PagerDuty 服務(wù)檢查當(dāng)前是否存在活躍事件回顧過(guò)去 90 天的事件記錄并將 Pull Request 中涉及的文件與過(guò)去事件中涉及的區(qū)域進(jìn)行比較。這一次風(fēng)險(xiǎn)較低。當(dāng)前沒(méi)有活躍事件當(dāng)前修改也沒(méi)有與過(guò)去的事件表現(xiàn)出明顯關(guān)聯(lián)。因此Agent 建議繼續(xù)推進(jìn)。整個(gè)過(guò)程沒(méi)有發(fā)生什么戲劇性的事情但這正是重點(diǎn)。部署風(fēng)險(xiǎn)檢查不再是只有當(dāng)某次發(fā)布看起來(lái)已經(jīng)非常危險(xiǎn)時(shí)才會(huì)進(jìn)行的操作而是成為 Pull Request 中一個(gè)常規(guī)的步驟。有什么變化你仍然在使用 Amplitude、LaunchDarkly、Endor Labs 和 PagerDuty。但現(xiàn)在你不再需要在這些工具之間不斷轉(zhuǎn)移上下文它們都可以直接融入 GitHub 工作流。隨著工作從想法逐步走向生產(chǎn)環(huán)境開(kāi)發(fā)者可以在某項(xiàng)服務(wù)的上下文或能力發(fā)揮作用時(shí)將其引入 GitHub。借助 Agent AppsGitHub 成為了開(kāi)發(fā)者與 Agent 協(xié)調(diào)下一步工作的中心而開(kāi)發(fā)者無(wú)需不斷切換工作上下文。開(kāi)始使用Agent Apps 已經(jīng)可以通過(guò) GitHub Marketplace 獲取。安裝其中一個(gè)為組織啟用然后開(kāi)始體驗(yàn)將 Agent 分配給一個(gè) Issue啟動(dòng)任務(wù)。在 Pull Request 評(píng)論中使用mention讓 Agent 進(jìn)行分析或執(zhí)行操作。在代碼倉(cāng)庫(kù)的Agents選項(xiàng)卡中選擇 Agent。你的工具仍然是你的工具?，F(xiàn)在它們會(huì)出現(xiàn)在你已經(jīng)工作的地方——GitHub。探索其他首批推出的 Agent Apps將你的技術(shù)棧直接帶入現(xiàn)有工作流Packfiles 的 Agent 可以讀取你的 Backlog并制定遷移策略。Miro 的 Agent 可以將可視化協(xié)作與代碼工作流連接起來(lái)。Bright Security 的 Agent 可以在 GitHub 中自主執(zhí)行端到端動(dòng)態(tài)安全測(cè)試。SonarQube 的 Agent 可以將代碼分析、質(zhì)量門禁和問(wèn)題修復(fù)能力帶入 GitHub Agent 會(huì)話。Octopus Deploy 的 Agent 可以識(shí)別、診斷并解決部署失敗問(wèn)題。探索 GitHub Marketplace 中的 Agent Apps 技術(shù)速遞｜如何通過(guò) Agent Apps 將軟件交付工作流引入 GitHub
作者Sam Zhang排版Alan Wang了解 GitHub 中的四款 Agent App 如何幫助你在整個(gè)軟件開(kāi)發(fā)生命周期SDLC中完成需求范圍界定、安全保障、逐步發(fā)布和功能交付并且全程無(wú)需離開(kāi) GitHub。你在 Pull Request 旁邊還打開(kāi)了多少個(gè)標(biāo)簽頁(yè)想象一下你正在處理產(chǎn)品免費(fèi)試用引導(dǎo)流程中的一個(gè)新 Issue將“邀請(qǐng)你的團(tuán)隊(duì)成員”這一步設(shè)為可選。隨著注冊(cè)量不斷增加支持團(tuán)隊(duì)一直反饋這一步會(huì)給用戶帶來(lái)阻礙?？雌饋?lái)是個(gè)很容易解決的問(wèn)題對(duì)吧但從需求范圍界定到部署你需要回答以下四個(gè)問(wèn)題這真的是正確的修改方向嗎我正在修改的依賴項(xiàng)是否安全可靠如何安全地逐步發(fā)布現(xiàn)在適合進(jìn)行部署嗎每個(gè)問(wèn)題的答案都來(lái)自不同的工具因此處理這個(gè) Pull Request 時(shí)你需要在四個(gè)不同的地方之間不斷傳遞相同的上下文。GitHub Agent Apps 將回答這些問(wèn)題所需的工具帶到了你已經(jīng)工作的地方并使用與 GitHub 自身 Copilot Cloud Agent 相同的平臺(tái)和運(yùn)行框架。下面的示例演示了如何使用你已經(jīng)依賴的服務(wù)例如 Amplitude、Endor Labs、LaunchDarkly 和 PagerDuty在完全不離開(kāi) GitHub 的情況下回答這些問(wèn)題并完成這項(xiàng)需求。開(kāi)始開(kāi)發(fā)之前支持團(tuán)隊(duì)表示對(duì)于正在使用產(chǎn)品進(jìn)行引導(dǎo)的客戶來(lái)說(shuō)“邀請(qǐng)你的團(tuán)隊(duì)成員”這一步很令人困擾但他們并沒(méi)有提供具體信息說(shuō)明究竟是誰(shuí)提出了投訴也沒(méi)有說(shuō)明這些投訴是否會(huì)導(dǎo)致用戶流失。對(duì)此保持懷疑是合理的。因此與其打開(kāi) Amplitude 并創(chuàng)建查詢來(lái)驗(yàn)證自己的判斷不如直接在 Agents 選項(xiàng)卡中向 AmplitudeAgent提問(wèn)Ampamplitude[agent] is completing the team invite step correlated with success later in the funnel? Break it down by segments were measuring.分析結(jié)果非常明確完成這一步的團(tuán)隊(duì)用戶后續(xù)留存的可能性更高而對(duì)于個(gè)人用戶則不存在這種相關(guān)性。因此重新界定需求范圍是合理的對(duì)于個(gè)人用戶的注冊(cè)流程可以將這一步延后而對(duì)于團(tuán)隊(duì)用戶則繼續(xù)保留現(xiàn)有流程?，F(xiàn)在你無(wú)需編寫任何代碼就可以直接在 GitHub 中獲取產(chǎn)品數(shù)據(jù)和洞察從而及時(shí)調(diào)整方向。開(kāi)發(fā)過(guò)程中Copilot 會(huì)針對(duì)這項(xiàng)修改創(chuàng)建一個(gè) Draft Pull Request。與此同時(shí)實(shí)現(xiàn)過(guò)程中還需要更新免費(fèi)試用引導(dǎo)流程所使用的依賴項(xiàng)。與其等到 CI 掃描失敗后再處理不如直接在評(píng)論中詢問(wèn) Endor Labs Agentendorendor-labs-github-agenthq[agent] is there anything I need to watch out for in the dependencies being touched by this pull request?該 Agent 會(huì)識(shí)別發(fā)生變更的依賴項(xiàng)檢查它們是否存在已知漏洞以及更廣泛的軟件包風(fēng)險(xiǎn)然后直接在 Pull Request 中返回分析結(jié)果。這一次一切看起來(lái)都很干凈沒(méi)有需要修復(fù)的問(wèn)題。依賴項(xiàng)審查因此成為修改仍處于當(dāng)前 Pull Request 階段時(shí)的一項(xiàng)主動(dòng)檢查而不是等 CI 掃描失敗后再進(jìn)行修復(fù)。顯然這種方式更加高效。發(fā)布過(guò)程中前面的分析結(jié)果現(xiàn)在會(huì)進(jìn)一步落實(shí)到實(shí)現(xiàn)中個(gè)人用戶注冊(cè)時(shí)進(jìn)入可選路徑而團(tuán)隊(duì)用戶繼續(xù)使用現(xiàn)有流程。由于這些用戶群體在注冊(cè)時(shí)就已經(jīng)確定因此可以直接通過(guò) Feature Flag 針對(duì)不同用戶群體進(jìn)行控制。你可以像向團(tuán)隊(duì)成員分配任務(wù)一樣請(qǐng) LaunchDarkly Agent 幫你完成設(shè)置darklylaunchdarkly-agent[agent] please create a feature flag for this pull request and wire it into the code. - key: defer-team-invite - type: boolean - default: false - target: solo-intent signups - rollout: internal 5% 25% 100%Agent 會(huì)在 LaunchDarkly 中創(chuàng)建 Feature Flag并將代碼實(shí)現(xiàn)作為一個(gè) Commit 添加到 Pull Request 中供你審核。如果目標(biāo)環(huán)境要求審批它會(huì)創(chuàng)建審批請(qǐng)求而不是直接應(yīng)用用戶定向配置。是否繼續(xù)推進(jìn)發(fā)布仍然由人來(lái)決定。Feature Flag 的配置流程因此從“切換到另一個(gè)工具、手動(dòng)交接代碼、再通過(guò) Slack 協(xié)調(diào)”變成一條 Pull Request 評(píng)論加一個(gè)供你審核的 Commit。發(fā)布之前代碼審查可以告訴你代碼本身是否正確但服務(wù)當(dāng)前是否處于適合部署的狀態(tài)則是另一個(gè)問(wèn)題。在合并之前你可以詢問(wèn) PagerDuty Agentpagerdutypagerduty-agent-app[agent] assess the deployment risk for this pull request against the onboarding service. Check active incidents and recent incident history, then recommend whether to proceed.Agent 會(huì)將代碼倉(cāng)庫(kù)映射到對(duì)應(yīng)的 PagerDuty 服務(wù)檢查當(dāng)前是否存在活躍事件回顧過(guò)去 90 天的事件記錄并將 Pull Request 中涉及的文件與過(guò)去事件中涉及的區(qū)域進(jìn)行比較。這一次風(fēng)險(xiǎn)較低。當(dāng)前沒(méi)有活躍事件當(dāng)前修改也沒(méi)有與過(guò)去的事件表現(xiàn)出明顯關(guān)聯(lián)。因此Agent 建議繼續(xù)推進(jìn)。整個(gè)過(guò)程沒(méi)有發(fā)生什么戲劇性的事情但這正是重點(diǎn)。部署風(fēng)險(xiǎn)檢查不再是只有當(dāng)某次發(fā)布看起來(lái)已經(jīng)非常危險(xiǎn)時(shí)才會(huì)進(jìn)行的操作而是成為 Pull Request 中一個(gè)常規(guī)的步驟。有什么變化你仍然在使用 Amplitude、LaunchDarkly、Endor Labs 和 PagerDuty。但現(xiàn)在你不再需要在這些工具之間不斷轉(zhuǎn)移上下文它們都可以直接融入 GitHub 工作流。隨著工作從想法逐步走向生產(chǎn)環(huán)境開(kāi)發(fā)者可以在某項(xiàng)服務(wù)的上下文或能力發(fā)揮作用時(shí)將其引入 GitHub。借助 Agent AppsGitHub 成為了開(kāi)發(fā)者與 Agent 協(xié)調(diào)下一步工作的中心而開(kāi)發(fā)者無(wú)需不斷切換工作上下文。開(kāi)始使用Agent Apps 已經(jīng)可以通過(guò) GitHub Marketplace 獲取。安裝其中一個(gè)為組織啟用然后開(kāi)始體驗(yàn)將 Agent 分配給一個(gè) Issue啟動(dòng)任務(wù)。在 Pull Request 評(píng)論中使用mention讓 Agent 進(jìn)行分析或執(zhí)行操作。在代碼倉(cāng)庫(kù)的Agents選項(xiàng)卡中選擇 Agent。你的工具仍然是你的工具?，F(xiàn)在它們會(huì)出現(xiàn)在你已經(jīng)工作的地方——GitHub。探索其他首批推出的 Agent Apps將你的技術(shù)棧直接帶入現(xiàn)有工作流Packfiles 的 Agent 可以讀取你的 Backlog并制定遷移策略。Miro 的 Agent 可以將可視化協(xié)作與代碼工作流連接起來(lái)。Bright Security 的 Agent 可以在 GitHub 中自主執(zhí)行端到端動(dòng)態(tài)安全測(cè)試。SonarQube 的 Agent 可以將代碼分析、質(zhì)量門禁和問(wèn)題修復(fù)能力帶入 GitHub Agent 會(huì)話。Octopus Deploy 的 Agent 可以識(shí)別、診斷并解決部署失敗問(wèn)題。探索 GitHub Marketplace 中的 Agent Apps