Chất Lượng và Thông Báo Trong Pipeline

Pipeline giờ có approval và trigger, nhưng còn thiếu hai thứ để vận hành thật. Thứ nhất: bảo đảm code hỏng không tới được Deploy — chạy test như một cổng chặn. Thứ hai: không ai ngồi nhìn console cả ngày, nên pipeline phải tự báo khi thành công, thất bại, hay chờ duyệt. Bài này (khép Part V) thêm cả hai.

Mục tiêu

Dùng test trong pipeline làm cổng chặn deploy, và dựng thông báo trạng thái pipeline ra SNS — kiểm chứng thông báo thật sự được gửi.

Test như cổng chặn

Stage Build của ta đã chạy pytest (bài 6). Trong pipeline, điều đó tự nhiên trở thành cổng chặn: nếu test trượt, buildspec trả mã khác 0, stage Build Failed, và pipeline dừng ngay — stage Approval và Deploy không bao giờ chạy. Không cần cấu hình gì thêm; chỉ cần đừng nuốt lỗi test (|| true) như đã cảnh báo ở bài 6.

Với dự án lớn, bạn có thể tách rõ thành stage Test riêng sau Build, hoặc thêm một action quét bảo mật (chạy trivy/checkov trong một CodeBuild project) ở cùng stage với runOrder song song. Dù tổ chức kiểu nào, nguyên tắc một: mọi cổng chất lượng nằm trước Deploy, và bất kỳ cổng nào fail thì pipeline dừng trước khi đụng tới production. Đây là điểm khiến pipeline khác một script deploy — nó từ chối đưa bản hỏng đi tiếp.

Vì sao cần thông báo

Một pipeline tự động mà không báo gì thì nguy hiểm: một deploy fail lúc 2 giờ sáng, hay một pipeline đang chờ duyệt mà không ai biết, có thể nằm im hàng giờ. Thông báo biến pipeline từ "im lặng chạy" thành "chủ động báo cáo". CodePipeline phát thông báo qua notification rule (dịch vụ CodeStar Notifications), đẩy sự kiện ra một SNS topic — từ đó tỏa đi email, Slack, hay một hàng đợi để xử lý tiếp.

Dựng SNS topic và notification rule

Tạo SNS topic làm điểm phát:

$ TOPIC=$(aws sns create-topic --name awscicd-notifications --query 'TopicArn' --output text)

Cho phép CodeStar Notifications publish vào topic (topic policy cho service codestar-notifications.amazonaws.com), rồi tạo notification rule gắn vào pipeline, chọn các sự kiện quan tâm:

$ aws codestar-notifications create-notification-rule \
    --name awscicd-pipeline-notifications \
    --resource arn:aws:codepipeline:ap-southeast-1:111122223333:awscicd-pipeline \
    --detail-type FULL \
    --event-type-ids \
       codepipeline-pipeline-pipeline-execution-succeeded \
       codepipeline-pipeline-pipeline-execution-failed \
       codepipeline-pipeline-manual-approval-needed \
    --targets "TargetType=SNS,TargetAddress=$TOPIC"

Ba event-type-ids nói rule chỉ bắn khi pipeline thành công, thất bại, hoặc cần duyệt — đúng những lúc cần biết. (Lần đầu tạo rule trong một tài khoản, AWS cần dựng service-linked role AWSServiceRoleForCodeStarNotifications; nếu gặp lỗi "could not create the managed rule", đợi vài phút cho role sẵn sàng rồi thử lại.)

Xác nhận rule bật và trỏ đúng topic:

$ aws codestar-notifications describe-notification-rule --arn <rule-arn> \
    --query '[Status,length(EventTypes),Targets[0].TargetAddress]' --output text
ENABLED  3  arn:aws:sns:ap-southeast-1:111122223333:awscicd-notifications

Kiểm chứng thông báo thật

Để chứng minh chuỗi hoạt động, đăng ký một hàng đợi SQS vào topic (thay vì email, vốn cần xác nhận tay) rồi đọc message. Sau khi chạy pipeline, một thông báo rơi vào SQS:

$ aws sqs receive-message --queue-url <queue> --wait-time-seconds 10 \
    --query 'Messages[0].Body' | ...
detailType: CodePipeline Action Execution State Change
source: aws.codepipeline
detail: {"pipeline": "awscicd-pipeline", "execution-id": "a9a2d677-...",
         "stage": "Approval", ...}

Thông báo thật, từ chính lần pipeline chạy: nó báo execution đang ở stage Approval (cần duyệt). Trong thực tế, cũng message này đi tới email hay một kênh Slack, để người trực biết pipeline đang chờ mình. Khi pipeline Failed hay Succeeded, một message tương tự được bắn ra.

   pipeline event (succeeded / failed / approval-needed)
        │
   notification rule (CodeStar Notifications)
        │  publish
        ▼
   SNS topic awscicd-notifications
        ├──▶ email (subscribe + confirm)
        ├──▶ Slack (qua AWS Chatbot)
        └──▶ SQS  ──▶ đọc được message thật (đã kiểm)

EventBridge: tùy biến sâu hơn

Notification rule bên dưới thực chất dựng một quy tắc EventBridge bắt sự kiện pipeline. Khi cần xử lý phức tạp hơn email/Slack — ví dụ gọi một Lambda để ghi metric, mở ticket, hay chặn deploy theo điều kiện ngoài — bạn viết thẳng một EventBridge rule trên pattern sự kiện CodePipeline (source: aws.codepipeline, detail-type: CodePipeline Pipeline Execution State Change) rồi trỏ target tới Lambda/SNS/SQS. Notification rule là lối tắt cho thông báo thông thường; EventBridge là cửa cho mọi tự động hóa quanh pipeline.

🧹 Dọn dẹp

Part V xong — dọn pipeline, EC2 target, và hạ tầng thông báo:

$ aws codepipeline delete-pipeline --name awscicd-pipeline
$ aws ec2 terminate-instances --instance-ids <target-iid>
$ aws codestar-notifications delete-notification-rule --arn <rule-arn>
$ aws sns delete-topic --topic-arn <topic>
$ aws sqs delete-queue --queue-url <queue>

Tổng kết

Hai thứ làm pipeline dùng được thật: test làm cổng chặn (Build chạy test, trượt thì pipeline dừng trước Deploy — mọi cổng chất lượng đặt trước Deploy), và thông báo để pipeline tự báo trạng thái. Thông báo dựng bằng notification rule (CodeStar Notifications) trỏ ra SNS topic, chọn sự kiện succeeded/failed/approval-needed, rồi tỏa đi email/Slack/SQS — ta đọc được message thật qua SQS để xác nhận. Bên dưới là EventBridge, cũng là cửa cho mọi tự động hóa sâu hơn quanh pipeline.

Part V khép lại: pipeline đã tự động, có approval, có cổng chất lượng, có thông báo. Part VI là capstone — ghép toàn bộ series thành một pipeline production hoàn chỉnh: từ commit CodeCommit, qua build và test, tới blue/green deploy lên Auto Scaling Group sau ALB, có approval và rollback. Bài tới dựng hạ tầng đích cho capstone bằng CLI.