Đêm 2 giờ sáng deploy mà toát mồ hôi hột - Tại sao Backend Developer phải học CI/CD nghiêm túc

Mở đầu

Mùa hè năm ngoái, lúc 2 giờ sáng, tôi đang SSH vào server và tay run run.

Đang deploy tính năng mới thì phát hiện thiếu 1 dòng trong migration script của database. Khi nhận ra thì cấu trúc bảng ở môi trường production đã bị hỏng, dịch vụ ngừng hoạt động. Trên Slack liên tục có báo cáo từ người dùng "Không đăng nhập được", "Lỗi thanh toán".

Cuối cùng mất 3 giờ để rollback, sáng hôm sau bị sếp gọi lên.

"Tại sao lại xảy ra chuyện này?"

Tôi trả lời thật "Vì làm thủ công nên mắc lỗi rồi ạ"

Từ ngày đó, tôi bắt đầu học CI/CD nghiêm túc.

Tại sao deploy thủ công lại nguy hiểm

Quy trình deploy của tôi lúc đó như sau:

1. Build code ở local
2. SSH vào server
3. Upload file thủ công
4. Chạy database migration
5. Restart service
6. Kiểm tra hoạt động

Các bạn có biết vấn đề ở đâu không?

Tất cả đều phụ thuộc vào trí nhớ và sự tập trung của con người

Tôi đã tạo checklist nhưng vẫn mắc lỗi. Vì sao?

• Làm việc đêm khuya nên giảm tập trung
• Quy trình quá nhiều bước, chắc chắn sẽ bỏ sót đâu đó
• Test với cảm giác "chắc là ổn"

Tại giai đoạn tăng trưởng nhanh của Tiki, đội ngũ backend cũng gặp phải "cơn ác mộng" khi triển khai.

Mỗi lần deploy đều phải thao tác thủ công vào server, build code, chạy migration database. Một lỗi nhỏ cũng có thể khiến hệ thống downtime hàng giờ. Kỹ sư trở nên e ngại commit code, quản lý thúc giục release, khách hàng phàn nàn, QA làm việc quá tải.

Mọi thứ thay đổi khi CI/CD được áp dụng.

CI/CD cuối cùng là gì?

CI/CD là viết tắt của "Continuous Integration / Continuous Deployment".

Tiếng Việt là "Tích hợp liên tục / Triển khai liên tục".

Nhưng chỉ giải thích thế này thì không hiểu gì cả.

Theo cách hiểu của tôi, CI/CD là cơ chế tự động làm tất cả sau khi commit code.

Cụ thể:

1. Push code lên Git
2. Tự động build
3. Tự động chạy test
4. Nếu test pass thì tự động deploy
5. Nếu fail thì tự động rollback

Nghĩa là, con người chỉ cần "viết code và push".

Còn lại, máy móc tự động làm hết.

Thực tế triển khai CI/CD

Công cụ đầu tiên tôi triển khai là GitHub Actions.

Lý do đơn giản, vì đang dùng GitHub. Không cần cài thêm tool, chỉ cần viết 1 file YAML là chạy được.

Workflow đầu tiên tôi tạo như sau:

name: CI-CD
on:
  push:
    branches: ["main"]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test
      - name: Build Docker image
        run: docker build -t app .
      - name: Deploy to Production
        run: ./deploy.sh

Chỉ cần đặt file YAML này vào .github/workflows/, mỗi lần push lên main branch thì tự động chạy test và deploy.

Ban đầu tôi còn nghi ngờ, nhưng khi thấy nó chạy thì cảm động thật.

"Cái này thực sự tự động làm hết à..."

Quản lý API là chìa khóa của tự động hóa

Sau khi triển khai CI/CD, tôi nhận ra quản lý API quyết định thành bại của tự động hóa.

Trong phát triển backend, thay đổi spec API xảy ra thường xuyên.

• Thêm endpoint
• Thay đổi kiểu parameter
• Thay đổi cấu trúc response

Nếu mỗi lần thay đổi phải thông báo thủ công cho frontend và QA team thì tự động hóa mất ý nghĩa.

Công cụ hữu ích ở đây là Apidog.

Apidog là công cụ có thể thiết kế API, tạo document, Mock server và test tự động. Kết hợp với CI/CD pipeline của backend development, có thể tối ưu hóa quản lý và test API.

Khi dùng Apidog:

• Thay đổi spec API tự động phản ánh vào document
• Mock server tự động cập nhật
• Frontend có thể phát triển mà không cần đợi implementation
• QA team có thể chạy test tự động mà không cần viết code

Nghĩa là, quản lý API cũng có thể tích hợp như một phần của tự động hóa.

Sau khi tích hợp Apidog vào CI/CD pipeline, việc phối hợp với frontend trở nên mượt mà.

Nỗi sợ database migration

Dù đã triển khai CI/CD, database migration vẫn đáng sợ.

Vì sao? Vì thay đổi database không thể quay lại.

Rollback code thì dễ, nhưng rollback database thì khó.

Đặc biệt khi môi trường production có lượng data lớn, nếu migration fail thì mất nhiều thời gian để phục hồi.

Phương pháp migration an toàn tôi học được:

1. PR phải đính kèm migration file
2. Chuẩn bị cả up (áp dụng) và down (rollback)
3. Nhất định phải test ở staging environment
4. Ưu tiên thay đổi tương thích (code cũ vẫn chạy được)
5. Thay đổi lớn thì release từng giai đoạn

Ví dụ, khi xóa column:

• Giai đoạn 1: Thêm column mới (giữ column cũ)
• Giai đoạn 2: Code đối ứng với column mới
• Giai đoạn 3: Xóa column cũ

Làm như vậy, dù rollback giữa chừng cũng không có vấn đề.

Chỉ số cần theo dõi trong CI/CD

Sau khi triển khai CI/CD, tôi bắt đầu theo dõi một số chỉ số.

Chỉ số	Giải thích	Giá trị lý tưởng
Deployment Frequency	Tần suất deploy	≥ 3 lần/ngày
Change Failure Rate	Tỷ lệ deploy fail	<5%
MTTR (Mean Time to Recovery)	Thời gian phục hồi sự cố	<15 phút
Lead Time	Từ commit đến release	Vài phút~1 giờ

Ban đầu deploy 1 lần/tuần, giờ deploy 3~5 lần/ngày.

Tỷ lệ deploy fail cũng giảm từ 20% xuống dưới 5%.

Quan trọng nhất, deploy không còn đáng sợ nữa.

Trước đây "Hôm nay deploy à? Nghiêm trọng đấy", giờ chỉ "Để tôi deploy tí".

Team nhỏ cũng triển khai được

"CI/CD chỉ dành cho công ty lớn phải không?" có thể bạn nghĩ vậy.

Nhưng tôi nghĩ team nhỏ mới cần CI/CD.

Vì sao? Vì ít người nên càng cần tăng hiệu quả bằng tự động hóa.

Team tôi chỉ có 3 người nhưng triển khai CI/CD trong 30 ngày.

Thời gian	Task
Tuần 1	Xây dựng chiến lược Git branch, triển khai GitHub Actions
Tuần 2	Triển khai API test tự động (sử dụng Apidog)
Tuần 3	Đóng gói Docker, xây dựng môi trường test tự động
Tuần 4	Graceful release, rollback & DB migration an toàn

Tuần đầu tốn chi phí học tập, nhưng từ tuần 2 hiệu quả bắt đầu tăng.

Đến tuần 4, công việc deploy gần như đã tự động hóa.

Tầm quan trọng của rollback và monitoring

Dù triển khai CI/CD, sự cố vẫn xảy ra.

Quan trọng là khi sự cố xảy ra có thể phục hồi nhanh không.

Chiến lược rollback tôi triển khai:

• Blue-Green Deploy: Chuẩn bị 2 môi trường mới-cũ, có thể chuyển đổi
• Feature Flag: Release tính năng mới từng giai đoạn, nếu có vấn đề thì vô hiệu hóa ngay
• Monitoring tự động: Phát hiện bất thường bằng Prometheus / Grafana / Datadog, thông báo qua Slack

Đặc biệt Feature Flag rất tiện.

Dù release tính năng mới, ban đầu chỉ công khai cho 10% user. Nếu không có vấn đề thì dần dần mở rộng đến 100%.

Nếu có vấn đề, chỉ cần tắt Feature Flag mà không cần rollback code.

Kết luận: CI/CD là văn hóa

Đã 1 năm kể từ khi triển khai CI/CD.

Nhìn lại, tôi cảm thấy CI/CD không chỉ là tool mà là văn hóa phát triển.

• Deploy không còn là nỗi sợ mà trở thành công việc hàng ngày
• Release nhỏ thường xuyên giúp phân tán rủi ro
• Có test tự động nên yên tâm refactoring

Nhìn vào case study của Tiki, CI/CD hoàn toàn thực tế ở thị trường Việt Nam.

Team nhỏ cũng có thể triển khai với chi phí thấp.

Nếu bạn đang SSH vào server lúc 2 giờ sáng và toát mồ hôi hột, hãy bắt đầu học CI/CD ngay.

Giống như tôi, trải nghiệm phát triển của bạn sẽ thay đổi hoàn toàn.

Nếu bài viết này hữu ích, hãy chia sẻ nhé. Nếu có câu hỏi hoặc comment, đừng ngại để lại.

FAQ (Câu hỏi thường gặp)

Q1: CI/CD là gì? A: Là phương pháp tự động hóa tích hợp, test và deploy code, giúp code chạy an toàn từ development đến production. Giảm công việc thủ công, tăng tần suất và chất lượng deploy.

Q2: Tool nào được khuyên dùng cho backend? A: GitHub Actions, Jenkins, GitLab CI là chính. Team nhỏ thì GitHub Actions dễ triển khai, quy mô lớn thì Jenkins hoặc GitLab CI có tính linh hoạt cao.

Q3: CI/CD có tăng độ tin cậy không? A: Có. Lặp lại test tự động và release nhỏ giúp giảm đáng kể tỷ lệ sự cố và thời gian phục hồi. Team tôi giảm tỷ lệ sự cố từ 20% xuống dưới 5%.

Q4: Chỉ số nào cần theo dõi trong CI/CD? A: 4 chỉ số: Tần suất deploy, Lead time thay đổi, Tỷ lệ thay đổi fail, Thời gian phục hồi trung bình (MTTR). Theo dõi những chỉ số này giúp đo lường hiệu quả CI/CD định lượng.

Q5: Database migration có thể làm an toàn không? A: Có. Migration tương thích, kiểm tra ở staging, rollback script giúp thực hiện an toàn. Quan trọng là release từng giai đoạn.