GitHub ra mắt Agent Apps: Tích hợp toàn bộ quy trình phát triển phần mềm vào nền tảng

Hãy xem cách bốn GitHub Agent Apps có thể giúp bạn xác định phạm vi, bảo mật, triển khai và phát hành một tính năng trong suốt vòng đời phát triển phần mềm (SDLC) – tất cả mà không cần rời khỏi GitHub.

14 tháng 8, 2026

4 phút

Bạn đang mở bao nhiêu tab bên cạnh pull request của mình?

Hãy tưởng tượng bạn đang xử lý một vấn đề mới trong luồng onboarding (hướng dẫn người dùng mới) của sản phẩm: làm cho bước “mời đồng đội” trở nên tùy chọn. Bộ phận hỗ trợ liên tục báo cáo rằng bước này là một điểm gây khó khăn khi số lượng đăng ký tăng lên. Một chiến thắng nhanh chóng, phải không?

Từ khâu xác định phạm vi đến triển khai, bạn cần câu trả lời cho bốn câu hỏi sau:

Mỗi câu trả lời nằm ở một công cụ khác nhau, vì vậy việc xử lý pull request đồng nghĩa với việc phải mang cùng một ngữ cảnh qua bốn nơi khác nhau.

Các GitHub agent apps mang những công cụ bạn cần để trả lời các câu hỏi đó đến ngay nơi bạn đang làm việc, được vận hành bởi cùng một nền tảng và cơ sở hạ tầng như Copilot cloud agent của chúng tôi. Hướng dẫn minh họa dưới đây cho thấy cách bạn có thể sử dụng các dịch vụ mà bạn vốn đã tin dùng, như Amplitude, Endor Labs, LaunchDarkly và PagerDuty để trả lời những câu hỏi này và hoàn thành yêu cầu, mà không bao giờ phải rời khỏi GitHub.

1. Trước khi bạn xây dựng

Bộ phận hỗ trợ cho biết bước “mời đồng đội” gây khó chịu cho khách hàng khi họ đang làm quen với sản phẩm, nhưng họ chưa đưa ra dấu hiệu về việc ai đã phàn nàn hoặc liệu những phàn nàn đó có dẫn đến việc rời bỏ dịch vụ (churn) hay không. Bạn hoàn toàn có lý khi hoài nghi. Vì vậy, thay vì mở Amplitude và xây dựng một truy vấn để xác nhận linh cảm của mình, bạn hãy hỏi agent của Amplitude ngay từ tab Agents:

Kết quả phân tách trả về rất rõ ràng: người dùng theo nhóm hoàn thành bước này có xu hướng gắn bó lâu dài hơn, trong khi người dùng cá nhân không có sự tương quan đó. Việc điều chỉnh lại phạm vi giờ đây đã có cơ sở: hoãn bước này đối với người dùng cá nhân và giữ lại cho các nhóm.

Quyền truy cập vào các thông tin chi tiết về sản phẩm giờ đây nằm ngay trong GitHub, cho phép điều chỉnh hướng đi trước khi bất kỳ dòng mã nào được viết.

2. Trong khi bạn xây dựng

Copilot mở một bản nháp pull request cho thay đổi này. Việc triển khai cũng cập nhật các phụ thuộc (dependencies) được sử dụng bởi luồng onboarding. Thay vì đợi CI scan thất bại sau đó, bạn hãy hỏi agent của Endor Labs trong một bình luận:

Agent xác định các phụ thuộc đã thay đổi, kiểm tra chúng để tìm các lỗ hổng đã biết và rủi ro gói rộng hơn, sau đó báo cáo lại trong pull request. Lần này, mọi thứ đều ổn. Không có gì cần phải khắc phục.

Đánh giá phụ thuộc trở thành một bước kiểm tra chủ động ngay khi thay đổi vẫn còn trước mắt bạn. Tốt hơn nhiều so với việc phải khắc phục sau khi CI scan thất bại.

3. Triển khai tính năng

Phát hiện trước đó giờ đây được đưa vào quá trình triển khai: người dùng cá nhân nhận được đường dẫn tùy chọn, trong khi các nhóm vẫn giữ nguyên đường dẫn hiện tại. Vì các phân khúc này được thiết lập khi đăng ký, một feature flag có thể nhắm mục tiêu trực tiếp đến họ. Hãy yêu cầu agent của LaunchDarkly thiết lập nó cho bạn, giống như cách bạn yêu cầu một thành viên trong nhóm:

Agent tạo flag trong LaunchDarkly và thêm mã triển khai dưới dạng một commit để bạn xem xét. Nếu môi trường mục tiêu yêu cầu phê duyệt, nó sẽ tạo một yêu cầu phê duyệt thay vì áp dụng thay đổi mục tiêu trực tiếp. Con người vẫn là người quyết định liệu việc triển khai có tiếp tục hay không.

Việc thiết lập flag chuyển từ quy trình sử dụng công cụ thứ hai, bàn giao mã thủ công và phối hợp qua Slack thành một bình luận trong pull request và một commit để bạn xem xét.

4. Trước khi bạn phát hành

Đánh giá cho thấy mã của bạn đã chính xác, nhưng liệu dịch vụ có đang ở trạng thái tốt để triển khai hay không lại là một câu hỏi khác. Trước khi merge, bạn hãy hỏi agent của PagerDuty:

Agent ánh xạ repository tới dịch vụ PagerDuty tương ứng, kiểm tra các sự cố đang hoạt động, xem xét 90 ngày trước đó và so sánh các tệp trong pull request với các khu vực liên quan đến các sự cố trong quá khứ.

Lần này, rủi ro ở mức thấp. Không có sự cố nào đang hoạt động và không có sự tương quan đáng kể nào với các thay đổi hiện tại. Khuyến nghị là hãy tiếp tục.

Không có gì kịch tính xảy ra, nhưng đó chính là mục đích. Kiểm tra rủi ro triển khai trở thành một bước thường lệ cho các pull request của bạn thay vì là việc bạn chỉ làm khi một bản phát hành đã có vẻ nguy hiểm.

Những gì thay đổi

Bạn vẫn sử dụng Amplitude, LaunchDarkly, Endor Labs và PagerDuty. Nhưng giờ đây, bạn không còn cần phải mang ngữ cảnh giữa chúng nữa, và tất cả sẽ hoạt động trực tiếp trong các quy trình làm việc trên GitHub của bạn.

Khi công việc chuyển từ ý tưởng sang sản xuất, các nhà phát triển có thể đưa từng dịch vụ vào GitHub khi ngữ cảnh hoặc khả năng của nó trở nên quan trọng. Với các agent apps, GitHub trở thành nơi các nhà phát triển và các agent phối hợp những gì sẽ xảy ra tiếp theo mà không cần phải chuyển đổi ngữ cảnh.

Hãy thử ngay

Agent Apps hiện đã có sẵn trên GitHub Marketplace. Hãy cài đặt một ứng dụng, kích hoạt nó cho tổ chức của bạn và trải nghiệm thử:

Các công cụ của bạn vẫn là của bạn. Giờ đây, chúng xuất hiện ngay nơi bạn đang làm việc: trên GitHub. Hãy khám phá các Agent Apps mới ra mắt khác và bắt đầu đưa stack công nghệ của bạn trực tiếp vào quy trình làm việc:

Tác giả

Quản lý sản phẩm, GitHub Copilot

Bài viết liên quan

Chúng tôi cũng có bản tin (newsletter)

Khám phá các mẹo, hướng dẫn kỹ thuật và các phương pháp tốt nhất trong bản tin hai tuần một lần dành riêng cho các nhà phát triển.

Địa chỉ email của bạn