Thảo luận về DevOps và CI/CD trong phương pháp phát triển phần mềm hiện đại

Hôm qua, tôi và những người bạn cũ – cựu sinh viên lớp chuyên ngành hẹp Công nghệ Phần mềm (Software Engineering) – Khoa CNTT Đại học Bách Khoa Hà Nội đã có dịp ngồi cafe ôn lại chuyện nghề. Chúng tôi nhớ về thời kỳ “oanh liệt” những năm đầu của thập niên 2000 anh em đã từng cùng nhau chiến đấu trong một số dự án phát triển phần mềm như phần mềm quản lý khách sạn, phần mềm dịch vụ giá trị gia tăng trên mạng di động, phần mềm ERP, v.v bằng máy Intel Pentium 4, quản lý source code bằng SVN, nơi mà việc tích hợp code (merge) là nỗi ám ảnh và mỗi lần triển khai phần mềm (deploy) là một cuộc chiến thủ công đầy rủi ro. So sánh với hiện tại, khi các ứng dụng phức tạp và hàng triệu người dùng như Mobile Banking app hay app Thương mại điện tử có thể tung ra bản cập nhật hàng ngày mà vẫn đảm bảo trải nghiệm mượt mà, sự khác biệt nằm ở đâu?

Câu trả lời không chỉ nằm ở công nghệ, mà nằm ở tư duy vận hành. Đó chính là sự ra đời của DevOps và quy trình CI/CD (Tích hợp & Triển khai liên tục).

Trong bài viết này, hãy cùng ITCOM mổ xẻ tường tận hai khái niệm này thông qua một ví dụ thực tế mà chúng tôi đã thảo luận: Cách một tính năng Mobile Banking đi từ những dòng code đầu tiên đến tay người dùng một cách an toàn nhất.

* Ghi chú: Bài viết này có nội dung hơi đi sâu vào yếu tố chuyên môn kỹ thuật về phương pháp và quy trình phát triển phần mềm hiện đại, phù hợp với độc giả là “anh em” làm quản lý về CNTT hơn là giới kinh doanh thuần túy.

1. Khái niệm cốt lõi

Trước khi đi vào ví dụ, hãy định nghĩa ngắn gọn:

• DevOps (Development + Operations): Không phải là một công cụ, mà là văn hóa và tư duy. Nó xóa bỏ bức tường ngăn cách giữa đội Lập trình (Dev – người viết code) và đội Vận hành (Ops – người quản lý server/hạ tầng). Mục tiêu: Làm việc cùng nhau để ra mắt tính năng nhanh hơn và ít lỗi hơn.
• CI/CD: Là công cụ và quy trình kỹ thuật để hiện thực hóa văn hóa DevOps.
  • CI (Continuous Integration – Tích hợp liên tục): Code của các lập trình viên được gộp chung vào kho lưu trữ và tự động kiểm tra lỗi thường xuyên (hàng ngày/hàng giờ).
  • CD (Continuous Delivery/Deployment – Chuyển giao/Triển khai liên tục): Tự động hóa việc đưa bản cập nhật đến tay người dùng (hoặc môi trường kiểm thử) một cách an toàn.

2. Ví dụ thực tế: Tính năng “Chuyển tiền bằng QR Code”

Giả sử Bank X muốn ra mắt tính năng Quét mã QR để chuyển tiền.

Kịch bản A: Khi KHÔNG CÓ DevOps và CI/CD (Cách làm cũ)

1. Code xong “ném qua tường”: 5 ông Dev viết code xong tính năng QR trong 2 tuần. Họ nén code lại thành một cục file zip hoặc merge code lộn xộn vào cuối tháng.
2. Xung đột (Merge Conflict): Ông A sửa file Login.java, ông B cũng sửa file đó. Khi gộp code lại, hệ thống báo lỗi be bét. Mất 2 ngày để sửa.
3. Build thủ công: Đội Dev gửi code cho đội QA (Tester). QA phải tự cài môi trường, tự bấm nút để tạo file cài đặt (.apk cho Android, .ipa cho iOS) trên máy tính cá nhân của họ.
4. “Works on my machine”: Dev bảo: “Trên máy tôi chạy ngon mà!”, nhưng khi đưa lên server thật hoặc máy Tester thì bị lỗi do thiếu thư viện hoặc cấu hình sai.
5. Triển khai rủi ro: Đêm thứ 6, đội Ops thức trắng để update server. Có lỗi xảy ra, khách hàng không đăng nhập được. Cả team hoảng loạn rollback (quay lại bản cũ).

Hậu quả: Tốn thời gian, nhiều lỗi, team đổ lỗi cho nhau, khách hàng tức giận.

Kịch bản B: Khi CÓ DevOps và CI/CD (Cách làm hiện đại)

Bây giờ, hãy xem quy trình (Pipeline) tự động hóa diễn ra như thế nào với tính năng QR Code:

Giai đoạn 1: Continuous Integration (CI) – Tích hợp liên tục

Bước 1: Commit Code (Viết và lưu code)

• Lập trình viên Nam viết xong hàm “Quét QR”. Nam đẩy (push) code lên hệ thống quản lý mã nguồn (như GitLab/GitHub).

Bước 2: Automated Build (Tự động đóng gói)

• Ngay khi Nam ấn “Push”, một hệ thống CI (như Jenkins hoặc GitHub Actions) tự động phát hiện code mới.
• Hệ thống tự động tải code về, cài đặt các thư viện cần thiết và đóng gói thành file ứng dụng (Build App).
  • Ví dụ: Nếu code sai cú pháp, hệ thống báo lỗi ngay lập tức qua Slack/Email cho Nam: “Build Failed”. Nam phải sửa ngay.

Bước 3: Automated Testing (Tự động kiểm thử)

• Hệ thống chạy các bài test tự động (Unit Test).
  • Test: “Nhập mã QR sai thì có báo lỗi không?”, “Số tiền âm thì có chặn không?”.
• Security Scan (Quan trọng cho Banking): Hệ thống tự động quét mã nguồn xem Nam có vô tình để lộ password database hay viết code có lỗ hổng bảo mật không (SAST).

Kết quả CI: Nếu tất cả đều xanh (Pass), chúng ta có một bản build sạch, đã được kiểm tra sơ bộ, sẵn sàng cho giai đoạn sau.

Giai đoạn 2: Continuous Delivery/Deployment (CD) – Triển khai liên tục

Bước 4: Deploy to Staging (Môi trường kiểm thử)

• Hệ thống CD tự động đẩy file ứng dụng vừa build lên kênh phân phối nội bộ (như Firebase App Distribution hoặc TestFlight).
• Đội QA/Tester nhận được thông báo, tải app về điện thoại thật để test tính năng QR. Họ không cần nhờ Dev build giúp nữa.

Bước 5: Deploy to Production (Môi trường thật)

• Sau khi QA chốt là “Ngon”, Giám đốc kỹ thuật bấm một nút “Approve” (hoặc tự động hoàn toàn nếu tin tưởng tuyệt đối).
• Hệ thống CD tự động:
  1. Tải bản App lên Apple App Store và Google Play Store.
  2. Cập nhật Backend Server (API) để hỗ trợ xử lý QR Code mà không cần tắt server (Zero-downtime deployment).

Bước 6: Monitoring (Giám sát)

• Ngay khi App lên Store, hệ thống giám sát (như Prometheus/Grafana) theo dõi:
  • Có bao nhiêu người đang dùng tính năng QR?
  • Tỷ lệ giao dịch lỗi là bao nhiêu?
• Nếu tỷ lệ lỗi đột ngột tăng vọt -> Hệ thống tự động cảnh báo hoặc tự động quay về bản cũ.

3. Bảng so sánh tóm tắt

4. Tổng kết

Trong ví dụ Mobile Banking:

• DevOps là việc anh Dev và anh Ops ngồi cùng nhau, thống nhất cách update app sao cho an toàn nhất.
• CI là cái máy tự động kiểm tra xem code tính năng QR có lỗi cú pháp hay bảo mật không.
• CD là cái máy tự động đưa tính năng QR đó đến máy của Tester và sau đó là lên App Store cho khách hàng dùng.