1. Continous Integration (CI)
CI/CD là gì?
CI/CD là viết tăt của hai khái niệm chính Continuous Integration (Tích hợp liên tục) và Continuous Delivery/Deployment (Chuyển giao/Triển khai liên tục). Đây là một phương pháp tự động hóa quy trình phát triển phần mềm, giúp việc đưa sản phẩm từ lập trình đến người sử dụng một cách nhanh chóng, an toàn và đáng tin cậy.
CI – Continuous Integration (Tích hợp liên tục)
Tích hợp liên tục là việc người lập trình thường xuyên (có thề nhiều lần trong ngày) hợp nhất (merge) mã nguồn vào kho chứa mã chung (central repository) ví dụ như git, svn, …
Công việc của Continous Integration như sau: Khi có một sự thay đổi được đẩy lên (push) repository, hệ thống sẽ thực hiện các bước sau:
– Build: Biên dịch mã nguồn thành phần mềm chạy được
– Test: Chạy các bài kiểm thử tự động (unit test, integration test) để đảm bảo những thay đổi mới không làm hỏng những gì đang có.
Mục tiêu của CI:
– Phát hiện và sửa lỗi sớm nhất có thể (Fast Failed): Thay vì đợi đến cuối mới tích hợp và đối mặt với một mớ bòng bong lỗi, chúng ta giải quyết từng vấn đề nhỏ ngay khi nó phát sinh.
– Tiết kiệm chi phí
2. Continuous Delivery/Deployment (CD)
2.1 Continuous Delivery (Chuyển giao liên tục): là một phương pháp phát triển phần mềm mà ở đó, mọi thay đổi về code, đã được xây dựng, kiểm thử và chuẩn bị để phát hành một cách tự động và liên tục, đảm bảo phần mềm có thể được triển khai bất cứ lúc nào.
Hãy tưởng tượng một dây chuyền sản xuất ô tô. Dây chuyền này (pipeline) liên tục lắp ráp, kiểm tra chất lượng, và cho ra những chiếc xe hoàn chỉnh. Những chiếc xe này được đưa vào 1 kho chưa, để sẵn sàng xuất xưởng. Tuy nhiên khi nào xuiất xưởng đến đại lý/người dùng là do phòng kinh doanh.
Trong sản xuất phần mềm:
– Chiếc xe hoàn chỉnh: là phiên bản phần mềm mới của bạn
– Kho chứa: là môi trường Staging hoặc một trạng thái “sẵn sàng triển khai”
– Quyết định của phòng kinh doanh chính là cổng phê duyệt thủ công cuối cùng trước khi đưa sản phẩm đến tay người dùng.
2.2 Triểt lý “Luôn sẵn sàng”: Mục tiêu chính của Continuous Delivery không phải là “triển khai nhiều hơn”, mà là “giảm thiểu rủi ro cho mỗi lần triển khai”
Trong mô hình truyền thống, các đội thường dồn hàng trăm thay đổi trong nhiều tuần hoặc tháng vào một bản phát hành “khổng lồ”. Điều ngày biến ngày ra mắt thành một sự kiện căng thẳng, rủi ro và khó sửa lỗi nếu có sự cố.
Continuous Delivery thay đổi điều đó bằng cách đảm bảo rằng mỗi thay đổi nhỏ đều đã được kiểm tra kỹ lượng và sẵn sàng. Nó biến việc phát hành từ một sự kiến đáng sợ thành một hoạt động nhàm chán, có thể dự đoán và lặp lại được. Mực tiêu là xây dựng sự tự tin rằng nút “Deploy to Production” có thể nhấn bất cứ lúc nào một các an toàn
2.3 Giải phẫu một đường ống Continuous Delivery (CD Pippline)
Giai đoạn 1: Tích hợp liên tục (CI Phase)
Đây là nền tảng của CD. Mỗi khi developer commit code, pipeline sẽ tự động:
– Build & Complie: Biên dịch mã nguồn thành một gói phần mềm chạy được (artifact)
– Unit & Integration Test: Chạy các bài kiểm thử ở mức độ đơn vị và tích hợp để đảm bảo các thành phần nội bộ hoạt động đúng như mong đợi. Nếu giai đoạn này thất bại, pipeline sẽ dừng lại và thông báo ngay cho lập trình viên.
Giai đoạn 2: Giai đoạn Chấp nhận (Acceptance Phase)
Khi artifact đã vượt qua CI, nó sẽ được triển khai lên một môi trường giống hệt Production (thường gọi là Staging). Tại đây các bài kiểm thử ở mức độ cao cấp hơn được thực hiện.
– Automated Acceptance/E2E Tests: Chạy các kịch bản mô phỏng hành vi của người dùng cuối để xác minh các luồng nghiệp vụ quan trọng.
– Performance & Load Tests: (Tùy chọn) Kiểm tra xem phiên bản mới có đáp ứng các yêu cầu về hiệu năng và chịu tải không.
– Security Scans: (Tùy chọn) Quét các lỗ hổng bảo mật. Giai đoạn này xác nhận rằng phiên bản mới không chỉ đúng về mặt kỹ thuật mà còn đáp ứng yêu cầu kinh doanh.
Giai đoạn 3: Cổng Phê duyệt Thủ công (The Manual Approval Gate)
Đây là trái tim của Continuous Delivery. Sau khi vượt qua tất cả các bài test tự động, pipeline sẽ dừng lại và chờ sự phê duyệt.
– Ai phê duyệt? Product Manager, QA Lead, hoặc một bên liên quan về kinh doanh.
– Họ làm gì? Họ có thể thực hiện một số kiểm tra thủ công cuối cùng (exploratory testing) trên môi trường Staging hoặc đơn giản là xác nhận rằng đây là thời điểm thích hợp để ra mắt dựa trên kế hoạch kinh doanh.
Giai đoạn 4: Triển khai Lên Production (Release Phase)
Khi nút “Approve” được nhấn, quá trình triển khai cuối cùng sẽ diễn ra. Quan trọng là, bản thân hành động triển khai này phải được tự động hóa hoàn toàn (thường được gọi là “One-Click Deploy”).
Giai đoạn này có thể sử dụng các kỹ thuật an toàn như Blue-Green hoặc Canary Deployment để giảm thiểu rủi ro.
2.4. Khi nào nên chọn Continuous Delivery?
Continuous Delivery là lựa chọn chiến lược khi bạn muốn cân bằng giữa tốc độ phát triển và sự kiểm soát của kinh doanh.
– Khi các quyết định kinh doanh là tối quan trọng: Cần đồng bộ việc ra mắt tính năng với một chiến dịch marketing, một thông cáo báo chí, hoặc một sự kiện lớn.
– Khi có yêu cầu về Quy định & Tuân thủ (Compliance): Các ngành như tài chính, y tế thường yêu cầu một quy trình phê duyệt và kiểm toán rõ ràng trước mỗi lần triển khai.
– Khi cần sự xác nhận từ nhiều bên: Một tính năng mới có thể cần đội ngũ Hỗ trợ khách hàng (Support) và Kinh doanh (Sales) được đào tạo trước khi ra mắt cho người dùng.
– Khi tổ chức chưa sẵn sàng cho Continuous Deployment: CD là một bước đệm tuyệt vời để xây dựng niềm tin vào quy trình tự động hóa trước khi tiến tới loại bỏ hoàn toàn cổng phê duyệt thủ công.
Tóm lại, Continuous Delivery trao quyền cho đội ngũ phát triển để họ luôn có một sản phẩm sẵn sàng, đồng thời trao quyền cho đội ngũ kinh doanh để họ quyết định thời điểm tốt nhất để mang sản phẩm đó ra thị trường.
3. Continuous Deployment (Triển khai Liên tục)
3.1 Phân biệt: Delivery vs. Deployment
Nhiều người thường nhầm lẫn giữa hai khái niệm này. Cả hai đều bắt đầu sau khi giai đoạn Tích hợp Liên tục (CI) thành công (code đã được build và vượt qua các bài test tự động).
Continuous Delivery (Chuyển giao liên tục):
– Mục tiêu: Luôn có một phiên bản sẵn sàng để ra mắt.
– Quy trình: Sau khi CI thành công, phiên bản mới được tự động triển khai lên một môi trường tương tự production (gọi là Staging). Mọi bài kiểm thử cuối cùng đều được thực hiện ở đây.
– Điểm chốt: Việc triển khai lên môi trường Production thật cần một cú nhấp chuột (quyết định thủ công) của con người.
Continuous Deployment (Triển khai liên tục):
– Mục tiêu: Tự động hóa toàn bộ quá trình từ code commit đến production.
– Quy trình: Nếu phiên bản mới vượt qua TẤT CẢ các bài kiểm thử tự động (bao gồm cả ở môi trường Staging), nó sẽ được tự động triển khai thẳng lên Production mà không cần bất kỳ sự can thiệp nào.
Bảng so sánh trực quan:
| Giai đoạn | Continuous Delivery | Continuous Deployment |
| Commit Code | Tự động | Tự động |
| Build & Unit Test | Tự động | Tự động |
| Deploy to Staging | Tự động | Tự động |
| Acceptance Tests | Tự động | Tự động |
| Deploy to Production | THỦ CÔNG Approval | TỰ ĐỘNG |
Nói cách khác, Continuous Deployment là bước tiến cao nhất của Continuous Delivery. Nó loại bỏ hoàn toàn nút thắt cổ chai cuối cùng: sự phê duyệt của con người.
3.2 Triết lý của Continuous Deployment
Nghe có vẻ đáng sợ khi để máy móc tự đẩy code lên cho hàng triệu người dùng. Nhưng triết lý của CD lại cho rằng việc này an toàn hơn vì:
– Rủi ro thấp hơn: Mỗi lần triển khai chỉ bao gồm một vài thay đổi rất nhỏ. Nếu có lỗi, bạn biết chính xác nó nằm ở đâu và việc sửa chữa (hoặc rollback) cực kỳ nhanh chóng. Điều này an toàn hơn nhiều so với việc triển khai một “gói” thay đổi khổng lồ sau nhiều tháng.
– Phản hồi nhanh hơn: Bạn nhận được phản hồi từ người dùng cuối gần như ngay lập tức. Điều này giúp đội ngũ sản phẩm biết được tính năng có được yêu thích hay không và nhanh chóng điều chỉnh.
– Năng suất cao hơn: Lập trình viên có thể tập trung hoàn toàn vào việc tạo ra giá trị, không còn phải lo lắng về “ngày triển khai” đầy áp lực.
3.3 Các Trụ cột Bắt buộc để CD thành công
Để tự tin trao “chìa khóa” production cho máy móc, bạn phải xây dựng một nền móng cực kỳ vững chắc.
3.3.1. Kim Tự Tháp Kiểm thử Tự động (Test Automation Pyramid)
Đây là điều kiện tiên quyết. Nếu không có hệ thống test tự động đáng tin cậy, CD là bất khả thi.
– Unit Tests (Nền tảng): Nhanh và rẻ tiền, kiểm tra từng đơn vị code nhỏ nhất. Phải có độ bao phủ (coverage) cao.
– Integration Tests (Tầng giữa): Kiểm tra sự tương tác giữa các module hoặc service.
– End-to-End (E2E) Tests (Đỉnh): Mô phỏng lại hành vi của người dùng trên toàn bộ ứng dụng. Chúng chậm và đắt đỏ, vì vậy chỉ nên có một số lượng vừa phải cho các luồng quan trọng nhất.
3.3.2. Pipeline CD vững chắc
Một pipeline CD mẫu sẽ có các bước sau, và chỉ cần một bước thất bại, toàn bộ quá trình sẽ dừng lại.
– Trigger: Lập trình viên commit code lên nhánh chính (main/master).
– Build & Unit Test: Hệ thống CI build mã nguồn và chạy toàn bộ unit test.
– Deploy to Staging: Nếu thành công, triển khai phiên bản mới lên môi trường Staging (giống hệt Production).
– Run Acceptance Tests: Chạy các bài test cao cấp hơn (Integration, E2E) trên môi trường Staging.
– THE GATE: Nếu tất cả các bước trên đều thành công 100% -> Tự động triển khai lên Production.
3.3.3. Giám sát và Quan sát (Monitoring & Observability)
Việc triển khai không kết thúc khi code đã lên production. Bạn phải có khả năng trả lời câu hỏi “Hệ thống có đang hoạt động ổn không?” ngay lập tức.
– Monitoring: Theo dõi các chỉ số quan trọng (CPU, memory, lỗi HTTP 5xx, độ trễ).
– Alerting: Tự động cảnh báo cho đội ngũ khi có chỉ số bất thường.
– Logging: Ghi lại toàn bộ log để có thể truy vết khi có lỗi.
4. Các Kỹ thuật Triển khai An toàn (Safety Nets)
Ngay cả với hệ thống test hoàn hảo, vẫn có những rủi ro không lường trước. Các kỹ thuật sau giúp giảm thiểu tác động của lỗi.
4.4.1. Blue-Green Deployment
– Ý tưởng: Bạn có hai môi trường Production giống hệt nhau: “Blue” (đang chạy phiên bản cũ) và “Green” (phiên bản mới).
– Quy trình: Pipeline sẽ triển khai phiên bản mới lên môi trường “Green”. Sau khi kiểm tra mọi thứ trên “Green” đều ổn, bạn chỉ cần chuyển hướng người dùng (router/load balancer) từ “Blue” sang “Green”.
Ưu điểm
– Rollback nhanh: Nếu Green bị lỗi thì quay lại Blue nhanh chóng
– Không có Downtime: Việc chuyển đổi traffic diễn ra gần như ngay lập tức, người dùng cuối không hề cảm nhận được sự gián đoạn.
– Kiểm thử toàn diện: Môi trường Green là một bản sao chính xác của Production, nên việc triển khai trên môi trường Green là một biện pháp test toàn diện.
Nhược điểm
– Chi phí tốn kém: Bạn phải vận hành gấp đôi tài nguyên hạ tầng trong một khoảng thời gian. Với các hệ thống lớn, chi phí này có thể rất cao.
– Phức tạp khi xử lý Database: Đây là thách thức lớn nhất. Nếu phiên bản mới yêu cầu thay đổi cấu trúc database (schema migration) mà phiên bản cũ không tương thích, việc rollback sẽ làm lỗi phiên bản cũ. Điều này đòi hỏi các chiến lược quản lý database phức tạp.
– Khó xử lý các phiên giao dịch dài (Long-running transactions): Các tác vụ đang chạy dang dở trên môi trường Blue có thể bị mất khi traffic đột ngột chuyển sang Green.
4.4.2. Canary Deployment
– Ý tưởng: Bạn tung ra phiên bản mới cho một lượng nhỏ người dùng trước (ví dụ: 1-5%).
– Quy trình: Pipeline triển khai phiên bản mới và chỉ điều hướng một phần nhỏ traffic đến nó. Hệ thống monitoring sẽ theo dõi chặt chẽ nhóm người dùng “canary” này. Nếu không có lỗi, bạn sẽ từ từ tăng lượng traffic cho phiên bản mới đến khi đạt 100%.
Ưu điểm
– Giảm bán kính ảnh hưởng: Nếu có lỗi, chỉ một phần nhỏ người dùng (ví dụ 1-5%) bị ảnh hưởng, thay vì toàn bộ hệ thống.
– Kiểm thử bằng người dùng thật: Bạn nhận được phản hồi và dữ liệu hiệu năng (lỗi, độ trễ) từ chính người dùng thực tế, đây là hình thức kiểm thử đáng tin cậy nhất.
– Triển khai với chi phí thấp hơn Blue-Green: Bạn không cần nhân đôi toàn bộ hạ tầng mà chỉ cần thêm một vài server/pod cho phiên bản canary.
Nhược điểm
– Quá trình ra mắt chậm: Việc theo dõi và tăng dần tỷ lệ traffic (1% -> 10% -> 50% -> 100%) cần thời gian. Nó không phù hợp cho các bản vá lỗi khẩn cấp.
– Yêu cầu hệ thống giám sát (Monitoring) cao cấp: Bạn phải có khả năng theo dõi và so sánh hiệu suất của nhóm canary với nhóm người dùng thông thường một cách chi tiết để phát hiện vấn đề.
– Vấn đề với Database và Caching: Tương tự Blue-Green, việc nhiều phiên bản code cùng hoạt động một lúc đòi hỏi database phải tương thích ngược. Dữ liệu cache cũng có thể trở nên không nhất quán.
4.4.3. Feature Flags (Feature Toggles)
– Ý tưởng: Tách biệt “Triển khai” (Deployment) và “Phát hành” (Release).
– Quy trình: Code cho một tính năng mới có thể được triển khai lên Production nhưng được “tắt” đi bởi một công tắc (flag). Tính năng này sẽ không hiển thị cho người dùng. Khi đội ngũ sản phẩm sẵn sàng, họ chỉ cần vào một giao diện quản lý và “bật” công tắc đó lên, không cần triển khai lại code.
Ưu điểm
– Tách biệt “Triển khai” và “Phát hành”: Đây là lợi ích thay đổi cuộc chơi. Code có thể được triển khai lên Production bất cứ lúc nào, nhưng đội ngũ sản phẩm/kinh doanh sẽ quyết định thời điểm “bật” tính năng cho người dùng.
– “Công tắc khẩn cấp” (Kill Switch): Nếu một tính năng gây lỗi nghiêm trọng, bạn có thể tắt nó đi ngay lập tức cho tất cả mọi người mà không cần rollback code.
– Phát hành có mục tiêu và thử nghiệm A/B: Bạn có thể bật một tính năng chỉ cho nhân viên nội bộ, cho một nhóm beta tester, hoặc cho 10% người dùng để thử nghiệm A/B, thu thập phản hồi trước khi ra mắt toàn bộ.
Nhược điểm
– Gia tăng Technical Debt: Đây là nhược điểm lớn nhất. Theo thời gian, code của bạn sẽ chứa đầy các câu lệnh if/else của các feature flag cũ. Nếu không có quy trình dọn dẹp nghiêm ngặt, codebase sẽ trở nên rất phức tạp.
– Tăng độ phức tạp khi kiểm thử: Bạn phải kiểm thử nhiều kịch bản hơn: tính năng A bật, B tắt; A tắt, B bật; cả hai cùng bật… Điều này có thể tạo ra một “vụ nổ tổ hợp” các trường hợp cần test.
– Chi phí quản lý: Cần có một hệ thống (tự xây dựng hoặc dịch vụ bên thứ ba như LaunchDarkly) để quản lý trạng thái của hàng trăm, hàng nghìn flag một cách hiệu quả.
Kết luận
Continuous Deployment không chỉ là một tập hợp công cụ, nó là một sự thay đổi về văn hóa và tư duy. Nó đòi hỏi sự tin tưởng tuyệt đối vào tự động hóa, một kỷ luật cao trong việc viết test, và sự hợp tác chặt chẽ giữa các đội (DevOps). Dù thách thức, nhưng phần thưởng mà CD mang lại—tốc độ, sự ổn định và khả năng sáng