Pipeline Thực Dụng: Approval Gate, Song Song, và Trigger

Pipeline ở bài trước tự động chạy thẳng từ commit tới production — nhanh, nhưng quá tự động cho nhiều đội: không ai kịp nhìn trước khi code lên prod. Pipeline production thực tế cần điểm dừng có người duyệt, chạy vài việc song song cho nhanh, và chỉ kích hoạt với đúng nhánh. Bài này thêm cả ba.

Mục tiêu

Thêm cổng phê duyệt thủ công và duyệt nó bằng CLI, hiểu runOrder để chạy action song song hay tuần tự, và lọc trigger theo nhánh.

Cổng phê duyệt thủ công

Chèn một stage Approval giữa Build và Deploy. Action loại Approval/Manual không làm gì ngoài dừng pipeline lại chờ người bấm duyệt:

{"name": "Approval", "actions": [{
  "name": "ManualApproval",
  "actionTypeId": {"category": "Approval", "owner": "AWS", "provider": "Manual", "version": "1"},
  "configuration": {"CustomData": "Phê duyệt để deploy lên production"},
  "runOrder": 1
}]}

Cập nhật pipeline (giờ 4 stage) rồi chạy:

$ aws codepipeline update-pipeline --cli-input-json file://pipeline.json \
    --query 'pipeline.stages[].name' --output text
Source  Build   Approval    Deploy

$ aws codepipeline start-pipeline-execution --name awscicd-pipeline

Poll trạng thái — pipeline chạy Source, Build, rồi dừng ở Approval:

$ aws codepipeline get-pipeline-state --name awscicd-pipeline \
    --query 'stageStates[].[stageName,latestExecution.status]' --output text
Source:Succeeded  Build:Succeeded  Approval:InProgress  Deploy:None

Approval:InProgress nghĩa là nó đang chờ. Deploy chưa chạy — không có gì lên prod tới khi được duyệt. Để duyệt bằng CLI, lấy token của action approval rồi gửi kết quả:

$ TOKEN=$(aws codepipeline get-pipeline-state --name awscicd-pipeline \
    --query "stageStates[?stageName=='Approval'].actionStates[0].latestExecution.token | [0]" --output text)

$ aws codepipeline put-approval-result --pipeline-name awscicd-pipeline \
    --stage-name Approval --action-name ManualApproval \
    --result summary="Đồng ý deploy",status=Approved --token "$TOKEN" \
    --query 'approvedAt' --output text
2026-05-25T13:51:12+07:00

Sau khi duyệt, pipeline chạy tiếp Deploy và hoàn tất:

$ aws codepipeline get-pipeline-execution --pipeline-name awscicd-pipeline \
    --pipeline-execution-id $EXID --query 'pipelineExecution.status' --output text
InProgress
...
Succeeded

Token là điểm cốt lõi: mỗi lần dừng approval sinh một token riêng, và put-approval-result phải kèm đúng token đó — nên không thể duyệt nhầm một execution cũ. Gửi status=Rejected thay vì Approved thì pipeline dừng hẳn, không deploy. Trong thực tế người ta duyệt qua console hoặc qua thông báo (bài 14), nhưng cơ chế bên dưới là cùng một token này.

   Source ─▶ Build ─▶ [ Approval: chờ người duyệt ] ─▶ Deploy
                            │
                            ├─ put-approval-result Approved (token) ─▶ chạy Deploy
                            └─ Rejected ─▶ pipeline dừng, không deploy

runOrder: song song hay tuần tự

Trong một stage, các action chạy theo runOrder: action cùng runOrder chạy song song, runOrder lớn hơn chạy sau. Ví dụ một stage Build chạy hai việc song song (build + lint) rồi một việc sau (gói):

"actions": [
  {"name": "Build", "runOrder": 1, ...},
  {"name": "Lint",  "runOrder": 1, ...},
  {"name": "Package", "runOrder": 2, ...}
]

Build và Lint (cùng runOrder 1) chạy đồng thời; Package (runOrder 2) chỉ chạy sau khi cả hai xong. Đây là cách rút ngắn pipeline: những việc độc lập (build nhiều thành phần, chạy nhiều bộ test) chạy song song thay vì xếp hàng.

Trigger: chỉ chạy với đúng nhánh

Mặc định pipeline chạy mỗi khi nhánh nguồn có commit. Pipeline type V2 cho lọc trigger tinh hơn — chỉ kích hoạt với đúng nhánh, tag, hay đường dẫn file. Khai trong triggers:

"triggers": [{
  "providerType": "CodeStarSourceConnection",
  "gitConfiguration": {
    "sourceActionName": "Source",
    "push": [{"branches": {"includes": ["main", "release/*"]}}]
  }
}]

Với cấu hình này pipeline chỉ chạy khi push lên main hoặc release/*, bỏ qua các nhánh feature — tránh tốn build/deploy cho nhánh chưa sẵn sàng. Lọc theo tag (chỉ deploy khi gắn tag phiên bản) hay theo file path (chỉ chạy khi thư mục nào đó đổi) cũng khai tương tự. Đây là tính năng chỉ có ở V2, một lý do nên dùng V2 cho pipeline mới.

🧹 Dọn dẹp

Pipeline + target dùng tiếp ở bài 14, giữ tới hết Part V. Lệnh xóa như bài 12.

Tổng kết

Ba thứ biến pipeline "chạy được" thành "dùng được": cổng phê duyệt thủ công (stage Approval/Manual dừng pipeline chờ put-approval-result kèm token — duyệt thì deploy, từ chối thì dừng); runOrder để chạy action song song (cùng số) hay tuần tự (số tăng dần), rút ngắn thời gian; và trigger lọc của V2 để pipeline chỉ chạy với đúng nhánh/tag/đường dẫn. Pipeline giờ có điểm kiểm soát của con người và chỉ chạy khi nên chạy.

Bài tới — khép Part V — gắn chất lượng và khả năng quan sát vào pipeline: chạy test/scan như một stage chặn, và bắn thông báo trạng thái pipeline (thành công, thất bại, chờ duyệt) ra SNS/email qua notification rule và EventBridge.