Merge queue yên vài phút, rồi ba pull request cùng vào gần như một lúc. Một test fail. Có người nói pipeline hỏng. Người khác nói release bị chặn. Hai chữ CI và CD bắt đầu xuất hiện trong chat như thể chúng là một thứ, nhưng thật ra chúng bảo vệ hai phần khác nhau của delivery flow.
Continuous Integration nói về việc integrate work vào shared codebase thường xuyên và an toàn. Thói quen cốt lõi là change nhỏ, merge thường xuyên, và automated check cho team biết main branch còn hoạt động không. CI không chỉ là một server chạy test. Nó là thỏa thuận của team rằng long-lived branch có rủi ro, integration nên diễn ra sớm, và shared code bị đỏ cần được chú ý nhanh.
CI tốt làm vấn đề hiện ra khi nó còn nhỏ. Developer đổi validation logic, unit test chạy, type check pass, lint bắt một import cẩu thả, và integration test tập trung xác minh boundary quan trọng. Nếu có gì fail, thay đổi vẫn còn mới trong đầu developer. Chi phí sửa thấp hơn vì team chưa chồng năm thay đổi không liên quan lên cùng một vùng uncertainty.
Continuous Delivery bắt đầu sau nền tảng đó. CD nghĩa là codebase được giữ trong trạng thái có thể release. Team có thể không deploy mọi change lên production tự động, nhưng đáng lẽ có thể release khi cần với sự tự tin. Điều đó cần nhiều hơn một unit test suite xanh. Nó cần packaging, configuration, migration, environment check, security control, release note, rollback thinking, và đủ automation để release là một hành động thường ngày thay vì sự kiện đặc biệt.
Continuous Deployment là bước xa hơn: mọi change vượt qua pipeline sẽ tự động vào production. Một số team dùng cách này an toàn, nhất là khi change nhỏ, observability mạnh, và feature flag kiểm soát exposure. Team khác cần manual approval vì regulation, hợp đồng khách hàng, release window hoặc product coordination. Điểm quan trọng là Continuous Delivery giữ hệ thống sẵn sàng release, còn Continuous Deployment thật sự release tự động.
CI thất bại khi main branch bị xem như nơi gặp nhau của những bất ngờ lớn. Một branch sống vài tuần có thể pass test của nó nhưng vẫn gãy khi merge vì thế giới bên dưới đã đổi. Branch càng sống lâu, integration càng trở thành một project riêng. Pull request nhỏ, trunk-based development, ownership rõ với red build, và feedback loop nhanh giúp CI không trở thành trình diễn.
CD thất bại khi pipeline dừng ở build success và bỏ qua thực tế production. Một package có thể build trong khi migration không an toàn. Một container có thể start trong khi default của feature flag sai. Một test có thể pass trong khi release không có rollback path. Delivery discipline bao gồm change backward-compatible, pattern expand-and-contract cho database, environment parity, smoke test, monitoring, và khả năng dừng hoặc đảo rollout khi signal xấu đi.
Feature flag thường nối CI và CD lại với nhau. Chúng cho phép behavior chưa hoàn chỉnh hoặc rủi ro sống trên main branch mà không lộ cho tất cả mọi người. Điều đó hỗ trợ integration thường xuyên trong khi vẫn giữ release control. Nhưng flag cần ownership và cleanup. Nếu không, codebase đầy những nhánh ẩn, và pipeline xanh có thể chỉ vì chưa ai test đúng tổ hợp flag.
Những hệ thống CI/CD tốt nhất có cảm giác hơi nhàm chán theo nghĩa tốt. Developer merge change nhỏ. Test phản hồi nhanh và có ích. Main branch khỏe. Release lặp lại được. Deployment có observability. Rollback đã được luyện. Khi có gì hỏng, team nhìn được change nào, environment nào, flag nào và metric nào đã dịch chuyển. Delivery bình tĩnh thường là kết quả của nhiều thỏa thuận nhỏ, không phải một tool đắt tiền.
Nếu team của bạn đang cải thiện khu vực này, hãy hỏi nỗi đau thật là gì. Change khó merge? Củng cố CI. Code đã merge nhưng release vẫn đáng sợ? Củng cố CD. Release đã đủ an toàn để tự động hóa hoàn toàn? Cân nhắc Continuous Deployment một cách cẩn thận. Acronym ít quan trọng hơn lời hứa phía sau chúng: shared code nên đáng tin, và việc đưa work hữu ích tới người dùng nên trở thành một thói quen được luyện, nhìn thấy được, và có thể đảo ngược.