Dùng AI để sinh và review pipeline GitHub Actions/GitLab CI
Playbook dùng AI để soạn và review YAML CI/CD mà vẫn giữ quyền quyết định cho đội DevOps: bắt đầu từ template, xác minh trigger và runner, dùng CI Lint hoặc workflow run, rồi review thay đổi như hạ tầng trước khi merge.
Một thay đổi YAML rất nhỏ có thể khiến pipeline chạy không đúng thời điểm. Chẳng hạn, với GitHub Actions, commit một workflow vào branch có thể kích hoạt sự kiện push. Với GitLab CI, các cấu hình như rules, needs, include, image hay environment đều cần được đọc kỹ trước khi merge.
AI có thể dựng nhanh khung pipeline, giải thích YAML và chỉ ra phần cấu hình lặp lại. Nhưng AI không nên là người quyết định cuối cùng cho thay đổi có tác động lớn.
Nguyên tắc đơn giản: AI soạn nháp và review vòng đầu; policy, kiểm tra pipeline và con người quyết định merge.
AI nên làm gì trong CI/CD?
GitHub Actions là nền tảng CI/CD để tự động hóa build, test và deploy. Workflow phải nằm trong thư mục .github/workflows, dùng đuôi .yml hoặc .yaml. GitHub cũng cung cấp các workflow template cho CI, deployment, automation, code scanning và Pages.
Trong GitLab, file .gitlab-ci.yml định nghĩa các job tạo thành pipeline. Một số từ khóa cấp pipeline gồm stages, variables, workflow và include. Các job có thể dùng những từ khóa như script, rules, needs, environment, image, artifacts, retry hoặc allowfailure.
Với nền tảng đó, AI phù hợp để:
Chuyển yêu cầu build, test hoặc deploy thành bản nháp YAML.
Giải thích trigger, thứ tự job và dependency.
Review thay đổi trong pull request/merge request.
Chỉ ra phần cấu hình cần người vận hành xác nhận.
Không nên để AI tự quyết các thay đổi liên quan production, secrets, identity, runner, image hoặc nguồn include bên ngoài.
Quy trình từ prompt đến pipeline có thể merge
1. Bắt đầu bằng template hoặc pipeline tối giản
Với GitHub Actions, hãy xem các template trong tab Actions hoặc kho actions/starter-workflows. GitHub có thể gợi ý template dựa trên mã nguồn của repository, ví dụ gợi ý cho dự án Node.js.
Trước khi yêu cầu AI viết pipeline đầy đủ, hãy xác nhận những điểm cơ bản: workflow có được phát hiện không, trigger có đúng không, runner có chạy được không và repository có được checkout không.
Ví dụ quickstart tối giản của GitHub Actions:
yaml
name: GitHub Actions Demo
run-name: ${{ github.actor }} is testing out GitHub Actions
on:
push
jobs:
Explore-GitHub-Actions:
runs-on: ubuntu-latest
steps:
run: echo "🎉 The job was automatically triggered by a ${{ github.eventname }} event."
run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"
name: Check out repository code
uses: actions/checkout@v6
name: List files in the repository
run: ls ${{ github.workspace }}
run: echo "🍏 This job's status is ${{ job.status }}."
Lưu file tại:
text
.github/workflows/github-actions-demo.yml
Khi commit file vào branch, sự kiện push sẽ kích hoạt workflow. Sau đó, vào tab Actions, chọn workflow run và mở job để kiểm tra log từng step.
Đây là điểm khởi đầu tốt trước khi thêm build, test hoặc deploy.
2. Prompt theo hợp đồng đầu ra
Đừng chỉ hỏi AI: “Viết giúp tôi CI.” Hãy nêu rõ mục tiêu, điều kiện chạy và những giới hạn không được vượt qua.
text
Bạn là reviewer CI/CD cho đội <team>.
Hãy tạo bản nháp <GitHub Actions|GitLab CI> cho repository <repository>.
Mục tiêu: <build/test/deploy>.
Chỉ chạy khi: <event hoặc điều kiện>.
Các stage/job mong muốn: <danh sách>.
Runner hoặc image đã được đội phê duyệt: <giá trị>.
Môi trường deploy: <environment>.
Điều không được làm:
Không tạo hoặc in secrets.
Không tự thêm external include.
Không tự thêm quyền truy cập, identity hoặc deploy production.
Không dùng job cho phép fail nếu không nêu rõ lý do.
Trả về:
YAML.
Giải thích trigger, thứ tự job và dependency.
Các giả định cần người review xác nhận.
Rủi ro vận hành và trường hợp pipeline không chạy.
Prompt review có thể dùng cho cả GitHub Actions lẫn GitLab CI:
text
Review file <.gitlab-ci.yml|workflow.yml> dưới góc nhìn DevOps/SRE.
Kiểm tra:
Trigger và điều kiện tạo pipeline/job có khớp mục đích không.
Job nào bị phụ thuộc sai hoặc có thể chạy sớm hơn.
Cấu hình dùng chung và cấu hình riêng của job có mâu thuẫn không.
include có nguồn nào cần xác minh không.
environment, image, artifacts, retry, allowfailure có cần review thêm không.
Thay đổi nào cần approval theo policy của đội.
Không khẳng định cấu hình đã chạy đúng nếu chưa có kết quả kiểm tra thực tế.
Trả về theo định dạng: phát hiện / tác động / cách sửa / mức ưu tiên.
Điểm GitLab dễ bị AI và người review bỏ sót
default không merge với cấu hình riêng của job
GitLab cho phép khai báo giá trị mặc định bằng default. Các giá trị này được áp dụng cho job chưa tự khai báo giá trị tương ứng.
Tuy nhiên, default không merge với cấu hình cùng tên đã có ở job. Nếu một job tự đặt image, job đó dùng image riêng thay vì image trong default.
Ví dụ:
yaml
default:
image: ruby:3.0
retry: 2
rspec:
script:
bundle exec rspec
rspec-2-7:
image: ruby:2.7
script:
bundle exec rspec
Trong ví dụ này:
rspec dùng image: ruby:3.0 và retry: 2.
rspec-2-7 dùng image: ruby:2.7, nhưng vẫn nhận retry: 2.
Khi AI đề xuất thay đổi default, hãy review từng job bị ảnh hưởng thay vì chỉ đọc phần YAML mới thêm.
include cần được xem như một dependency
GitLab hỗ trợ include từ local file, project, remote URL, template hoặc component. Các file được include được đánh giá trước, sau đó merge với .gitlab-ci.yml.
Cấu hình trong file .gitlab-ci.yml chính có thể override cấu hình include khi trùng tên job hoặc global keyword.
Khi AI đề xuất include, cần kiểm tra:
Nguồn include có thuộc phạm vi đội tin cậy hay không.
File chính đang override job hoặc cấu hình toàn cục nào.
Thay đổi ở nguồn include sẽ ảnh hưởng gì khi tạo pipeline mới.
GitLab nêu rõ: khi chạy lại một job, các file include không được tải lại. Nhưng khi chạy lại một pipeline, GitLab sẽ lấy lại các file include; nếu nguồn đã đổi, pipeline mới có thể dùng cấu hình mới.
Khóa thay đổi bằng kiểm tra và review
1. Review thay đổi pipeline như review hạ tầng
YAML pipeline cũng là cấu hình hạ tầng. Khi review, hãy trả lời được:
Event nào kích hoạt pipeline?
Điều kiện nào tạo hoặc bỏ qua job?
Job chạy trên runner hay image nào?
Job nào chạy theo thứ tự stage, job nào dùng needs?
Biến nào áp dụng toàn cục?
Artifact nào được truyền giữa các job?
Thay đổi nào có thể chạm môi trường deploy?
2. Dùng công cụ kiểm tra có sẵn
GitLab cung cấp CI Lint để validate .gitlab-ci.yml khi chỉnh sửa cấu hình.
Với GitHub Actions, quickstart hướng dẫn xác minh bằng cách commit workflow, mở workflow run trong tab Actions và xem log của từng job, từng step. Đây là cách trực tiếp để kiểm tra workflow có được kích hoạt và runner có thực thi các bước mong đợi hay không.
3. Mở rộng dần phạm vi
Bắt đầu từ workflow chỉ in thông tin event, runner, branch hoặc workspace. Khi đã xác nhận trigger và runner, mới thêm build và test.
Deploy nên được thêm sau cùng, cùng các kiểm soát phù hợp với policy của đội.
4. Không đưa secret vào prompt
Không dán token, private key, kubeconfig hay nội dung biến CI nhạy cảm vào chatbot.
Khi cần AI review cấu hình, dùng placeholder như:
text
<SECRETNAME>
<REGISTRY>
<PRODUCTIONENVIRONMENT>
AI vẫn có thể review cấu trúc pipeline mà không cần nhận secret thật.
Checklist trước khi merge YAML do AI tạo
[ ] Workflow GitHub Actions nằm trong .github/workflows và dùng đuôi .yml hoặc .yaml.
[ ] Trigger khớp ý định; không vô tình chạy thao tác nhạy cảm chỉ vì push.
[ ] Pipeline GitLab đã được kiểm tra bằng CI Lint.
[ ] GitHub workflow đã có workflow run và log được kiểm tra trong tab Actions.
[ ] default, include, rules, needs và các override giữa job đã được review.
[ ] Không có secret thật trong prompt, YAML, log hoặc comment.
[ ] Thay đổi liên quan production, environment, runner, image hoặc include đã qua approval theo policy nội bộ.
AI giúp giảm thời gian gõ YAML và hỗ trợ review vòng đầu. Nhưng pipeline chỉ đáng tin khi được đối xử như code: có kiểm tra, có log để quan sát và có người chịu trách nhiệm cho quyết định merge.