Sau khi đã biết cách kết nối GitLab MCP (Model Context Protocol — giao thức kết nối AI agent với công cụ ngoài) với từng agent CLI/IDE cụ thể, bài này ghép mọi thứ lại thành một workflow hoàn chỉnh, end-to-end: từ lúc bạn push code cho tới lúc MR được merge an toàn vào nhánh chính. Đây là quy trình đã được nhiều team engineering áp dụng thực tế, không phải lý thuyết — mỗi bước đều có prompt mẫu cụ thể, điểm cần con người can thiệp (human-in-the-loop), và cách xử lý khi có sự cố giữa đường.
Tổng Quan Workflow: Từ Push Code Đến Merge MR Bằng AI
Workflow gồm 4 giai đoạn chính, mỗi giai đoạn agent đảm nhận một phần việc cụ thể, xen giữa là các điểm approval của con người:
[Push code lên branch]
↓
[Giai đoạn 1: AI tạo MR — description, label, reviewer] ← human review description trước khi confirm tạo
↓
[Giai đoạn 2: Pipeline chạy — AI monitor + triage nếu fail] ← human confirm fix nếu pipeline fail
↓
[Giai đoạn 3: AI post comment review sơ bộ trên MR] ← human review comment, không tự merge
↓
[Giai đoạn 4: Human review cuối + click merge] ← luôn là con người, không giao cho AI
Nguyên tắc xuyên suốt: AI đảm nhận phần tốn thời gian lặp lại (viết description, đọc log dài, soát lỗi cơ bản), con người luôn giữ quyền quyết định ở các điểm không thể đảo ngược (merge, force push, xóa branch). Đây không phải giới hạn kỹ thuật mà là chủ đích thiết kế — một workflow tự động hóa tốt không có nghĩa là tự động hóa 100%, mà là tự động hóa đúng phần nên tự động hóa.
Về mặt hạ tầng, workflow này giả định bạn đã có:
- GitLab MCP server (ví dụ @zereight/mcp-gitlab) đã kết nối với agent CLI đang dùng (Claude Code, Gemini CLI, OpenCode, hoặc Cursor — như các bài trước trong module này).
- Access token với scope api và quyền tối thiểu Developer trên project liên quan.
- File .gitlab-ci.yml đã cấu hình pipeline chạy test/lint tự động khi có MR.
Mẹo: Trước khi áp dụng workflow này cho project thật, chạy thử toàn bộ 4 giai đoạn trên một project demo/sandbox GitLab riêng — không phải để test agent có "hoạt động" hay không, mà để chính bạn quen với việc approve từng bước, và điều chỉnh permission (allow/ask/deny) cho đúng mức độ tin tưởng của team trước khi đưa vào production.
Bước 1: AI Tự Sinh Mô Tả MR, Label, và Reviewer
Sau khi code đã commit ở local, thay vì tự viết MR description (một việc dễ bị làm qua loa cuối ngày), giao cho agent phần soạn thảo dựa trên diff thật:
Run `git diff main...HEAD` locally to see all my changes. Then create a merge request in project company/backend/payment-service from my current branch into main. Write the description in English with sections:
## What
## Why
## How to test
## Risk
Base the content strictly on the actual diff — don't invent test steps that aren't in the code. Add label "backend" and set reviewer to alice.nguyen based on our CODEOWNERS convention for files in src/services/.
Vài lưu ý thực chiến ở bước này:
- Yêu cầu agent "không được bịa" ("don't invent test steps that aren't in the code") là chi tiết nhỏ nhưng quan trọng — nếu không nhắc, model có xu hướng viết phần "How to test" nghe hợp lý nhưng không khớp thực tế, vì nó suy luận từ tên hàm/file thay vì test case thật đã chạy.
- Nếu team có quy tắc CODEOWNERS hoặc convention chọn reviewer theo thư mục, ghi rõ quy tắc này vào file
CLAUDE.md/AGENTS.md/context file tương ứng ở root repo — agent đọc và áp dụng tự động mỗi lần, không cần lặp lại trong từng prompt. - Luôn xem lại description trước khi agent thực sự gọi
create_merge_request— với các agent hỗ trợ dry-run, thêm câu "show me the description first, don't create yet" để có bước duyệt trung gian.
Sau khi MR được tạo, một pattern hữu ích khác là yêu cầu agent tự gắn milestone hoặc epic liên quan nếu công ty dùng GitLab Premium/Ultimate có các tính năng đó:
Link this merge request to milestone "Sprint 24" and epic "Payment Refund Improvements" if they exist in this project's group.
Mẹo: Với description tự sinh, luôn giữ nguyên phần "Risk" là mục bắt buộc trong template — đây là phần agent thường viết yếu nhất (dễ bỏ qua rủi ro non-obvious như race condition, backward compatibility), nên việc bắt buộc có mục này khiến model phải "suy nghĩ" về rủi ro thay vì chỉ tóm tắt code thay đổi.
Bước 2: Theo Dõi Trạng Thái Pipeline và Triage Lỗi Với MCP
Sau khi MR được tạo, pipeline CI/CD tự động chạy. Đây là bước agent hỗ trợ hiệu quả nhất trong toàn workflow, vì đọc log dài dòng, lặp lại là việc AI làm tốt hơn con người về tốc độ.
Theo dõi trạng thái:
Get the pipeline status for merge request !203 in project company/backend/payment-service. If it's still running, tell me which stage it's at. If any job has already failed, get its full log now.
Triage khi có job fail:
Job "unit-tests" failed in this pipeline. Fetch its log, extract the actual assertion error (ignore setup/teardown noise), and tell me:
1. Which test file and test function failed
2. What the expected vs actual value was
3. Your hypothesis for the root cause based on the diff of this MR
Phân loại lỗi flaky vs lỗi thật:
This is the 2nd time job "integration-tests" fails on this MR with a similar timeout error but at a different step each time. Based on the pattern, is this likely a flaky test (infra/timing issue) or a real regression from my changes? Explain your reasoning.
Phân loại flaky vs regression là bước cần nhiều kinh nghiệm senior — agent có thể hỗ trợ tốt nếu bạn cho nó đủ dữ liệu lịch sử (log của các lần chạy trước), nhưng quyết định cuối "có nên retry pipeline hay phải sửa code" vẫn nên do con người xác nhận, đặc biệt với lỗi liên quan tới business logic quan trọng như thanh toán.
Sau khi xác định root cause, agent có thể đề xuất fix cụ thể:
Based on the root cause you found, propose a code fix. Show me the diff you'd apply — don't push anything yet, just show me first.
Đây lại là một điểm dừng bắt buộc: xem diff đề xuất, tự quyết định áp dụng hay chỉnh sửa thêm, rồi mới yêu cầu agent thực thi (git commit, git push) để trigger lại pipeline.
Mẹo: Lưu lại log phân tích lỗi của agent (root cause, hypothesis) vào comment trên MR hoặc issue liên kết, dù bug đã fix xong — đây là tư liệu quý cho lần sau có lỗi tương tự, và cũng là cách xây "institutional knowledge" (kiến thức tổ chức) mà không cần ai ngồi viết postmortem thủ công.
Bước 3: Tự Động Comment Review Code Trên Merge Request
Khi pipeline đã pass, trước khi con người review cuối, để agent làm một lượt review sơ bộ giúp bắt các lỗi cơ bản (edge case thiếu, thiếu test, code style) — không phải để thay thế reviewer con người, mà để reviewer con người tập trung vào phần logic nghiệp vụ quan trọng hơn.
Yêu cầu review có cấu trúc rõ ràng:
Review the diff of merge request !203 in project company/backend/payment-service as a senior backend engineer would. Check specifically for:
1. Missing error handling or unchecked edge cases
2. Whether new logic has corresponding test coverage
3. Any hardcoded value that should be a config/env variable
4. Backward compatibility concerns with the API changes
For each finding, post an inline comment on the exact line in the diff. If you find nothing significant, don't post a comment just to seem thorough — only comment on real issues.
Câu cuối "don't post a comment just to seem thorough" quan trọng không kém phần yêu cầu review — nếu thiếu, agent có xu hướng cố tìm ít nhất một điểm để nói, dẫn tới comment vô nghĩa gây nhiễu cho reviewer con người đọc sau.
Review riêng phần bảo mật cho các MR động tới payment/auth:
This MR touches payment gateway integration code. Specifically check for: secrets/tokens accidentally logged in plaintext, missing input validation on amount fields, and any SQL query built with string concatenation instead of parameterized query. Report findings as a summary comment on the MR, tagged with severity (critical/major/minor).
Tổng hợp thành một comment tóm tắt cho reviewer con người:
Post a single summary comment on this MR titled "AI Pre-Review Summary" listing: files changed count, test coverage status, and top 3 risk points a human reviewer should focus on. Keep it under 150 words.
Comment tóm tắt này giúp reviewer con người không cần đọc lại toàn bộ diff từ đầu để nắm bối cảnh — họ đọc summary trước, biết chỗ nào cần soi kỹ, rồi mới vào review chi tiết.
Mẹo: Đặt rule permission cho tool comment (
create_merge_request_note) ở mức "allow" (không cần approve từng lần) nhưng tool merge/close luôn ở mức "ask" hoặc "deny" — comment là hành động dễ đảo ngược (xóa được), còn merge thì không, mức độ tự động hóa nên tương ứng với mức độ rủi ro của hành động, không phải cùng một mức cho tất cả.
Mẹo Thực Chiến
Tổng hợp kinh nghiệm khi vận hành toàn bộ workflow automation này trong môi trường production thật:
- Không bao giờ để AI tự merge dù pipeline pass và AI review không tìm thấy vấn đề — luôn giữ bước click merge cuối cùng là con người, kể cả với MR nhỏ trông "an toàn". Rủi ro không nằm ở việc AI sai nhiều, mà ở việc khi AI sai, nó thường sai một cách tự tin và khó phát hiện kịp nếu không có ai double-check.
- Đo lường hiệu quả bằng số liệu cụ thể, không chỉ cảm nhận: theo dõi thời gian trung bình từ push đến merge trước và sau khi áp dụng workflow này, số lượng bug được AI review bắt được trước khi tới reviewer con người, số lần AI review sai/nhiễu. Sau 4-6 tuần, review lại số liệu này để quyết định điều chỉnh prompt hay mở rộng phạm vi áp dụng.
- Chuẩn hóa prompt thành file dùng chung: lưu các prompt mẫu ở trên (tạo MR, triage pipeline, review code) thành slash command hoặc custom command trong agent CLI đang dùng (
.claude/commands/,.cursor/rules/...), để cả team gọi bằng một câu ngắn thay vì gõ lại prompt dài mỗi lần, và đảm bảo tính nhất quán giữa các thành viên. - Xử lý trường hợp AI review và pipeline pass nhưng vẫn có bug lọt qua production: đây là điều sẽ xảy ra — không có workflow nào 100% an toàn. Chuẩn bị sẵn quy trình rollback/hotfix rõ ràng, và dùng chính agent để hỗ trợ viết postmortem sau đó, biến sự cố thành dữ liệu cải thiện prompt cho lần sau.
Mẹo: Sau mỗi incident hoặc bug lọt qua workflow này, dành 10 phút hỏi lại agent "given this bug that slipped through, what would you check differently in future reviews" và lưu câu trả lời vào file convention chung của team — theo thời gian, đây trở thành một checklist review ngày càng sát với rủi ro thực tế của chính codebase bạn, không phải checklist chung chung copy từ đâu đó.