CI/CD là gì? Tìm hiểu khái niệm, quy trình và lợi ích cho phát triển phần mềm

Reading Time: 17 minutes

Việc phát triển và phát hành phần mềm có thể là một quá trình phức tạp, đặc biệt trong bối cảnh ứng dụng, đội ngũ và hạ tầng triển khai ngày càng mở rộng và đa dạng. Những thách thức này thường trở nên rõ nét hơn khi quy mô dự án tăng lên.

Để có thể phát triển, kiểm thử và phát hành phần mềm một cách nhanh chóng và nhất quán, các lập trình viên và tổ chức đã xây dựng ba chiến lược có liên quan chặt chẽ nhưng vẫn mang tính phân biệt, nhằm quản lý và tự động hóa các quy trình này.

1. Tích hợp liên tục (Continuous integration – CI) tập trung vào việc tích hợp công việc từ các nhà phát triển cá nhân vào repository chính nhiều lần trong ngày nhằm sớm phát hiện lỗi tích hợp và đẩy nhanh tiến độ phát triển hợp tác.
2. Phân phối liên tục (Continuous delivery – CD) chú trọng đến việc giảm ma sát trong quá trình triển khai hoặc phát hành, bằng cách tự động hóa các bước cần thiết để triển khai một bản build, từ đó có thể phát hành mã một cách an toàn vào bất kỳ thời điểm nào.
3. Triển khai liên tục (Continuous deployment) tiến thêm một bước bằng cách tự động triển khai mỗi khi có thay đổi trong mã nguồn.

Trong tài liệu này, chúng tôi sẽ phân tích chi tiết từng chiến lược, làm rõ mối liên hệ giữa chúng và trình bày cách tích hợp các chiến lược này vào vòng đời phát triển ứng dụng, từ đó cho thấy chúng có thể thay đổi phương thức phát triển và phát hành phần mềm của bạn như thế nào.

Để có cái nhìn rõ hơn về sự khác biệt giữa các dự án CI/CD mã nguồn mở, bạn hãy tham khảo phần so sánh công cụ CI/CD.

CI là gì? Lợi ích và vai trò trong phát triển phần mềm hiện đại

CI là một thực hành khuyến khích các nhà phát triển thường xuyên tích hợp mã của họ vào nhánh chính của repository. Thay vì xây dựng các tính năng một cách độc lập rồi mới tích hợp vào cuối chu kỳ phát triển, mỗi nhà phát triển sẽ tích hợp mã của mình với repository nhiều lần trong ngày.

Mục tiêu chính là giảm thiểu chi phí tích hợp bằng cách ưu tiên thực hiện ngay từ giai đoạn đầu. Lập trình viên có thể sớm phát hiện các xung đột giữa phần code mới và code hiện có, vào thời điểm mà những xung đột này vẫn còn tương đối dễ giải quyết. Một khi xung đột được xử lý, việc phát triển có thể tiếp tục trong tâm thế vững chắc rằng phần code mới đã tương thích với codebase hiện có.

Bản thân việc tích hợp code thường xuyên không thể đảm bảo về chất lượng của code hay chức năng mới. Trong nhiều tổ chức, quá trình tích hợp trở nên tốn kém vì phải dùng đến các quy trình thủ công để đảm bảo code mới đáp ứng tiêu chuẩn, không phát sinh bug và không phá vỡ các chức năng hiện có. Hơn nữa, việc tích hợp thường xuyên có thể gây ra mâu thuẫn khi phương pháp tự động hóa không đồng bộ với các quy trình đảm bảo chất lượng (QA) hiện hành.

Để giải quyết sự ma sát trong quá trình tích hợp, trên thực tế, CI dựa vào bộ kiểm thử mạnh và một hệ thống tự động để thực thi các bài kiểm thử đó. Khi một nhà phát triển hợp nhất mã vào repository chính, các quy trình tự động sẽ bắt đầu tiến trình build mã mới. Sau đó, các bộ kiểm thử được chạy trên bản build mới nhằm kiểm tra xem có vấn đề tích hợp nào phát sinh hay không. Nếu giai đoạn build hoặc kiểm thử thất bại, nhóm phát triển sẽ được cảnh báo để kịp thời xử lý và khắc phục.

Mục tiêu cuối cùng của CI là biến việc tích hợp thành một quy trình đơn giản, lặp lại được và trở thành một phần trong quy trình phát triển hàng ngày, từ đó giảm chi phí tích hợp và phát hiện lỗi sớm. Đảm bảo hệ thống có độ tin cậy cao, được tự động hóa và vận hành nhanh chóng, đồng thời xây dựng văn hóa làm việc nhóm khuyến khích lặp lại thường xuyên và phản ứng kịp thời với sự cố build, là những yếu tố cốt lõi để CI thành công.

Tìm hiểu CD: Bước đệm quan trọng từ tích hợp đến triển khai

CD là một phần mở rộng của CI. Phương pháp này tập trung vào việc tự động hóa quy trình chuyển giao phần mềm để các nhóm có thể dễ dàng và tự tin triển khai code của mình lên môi trường production bất cứ lúc nào. Nhờ duy trì codebase luôn trong trạng thái sẵn sàng phát hành, việc đưa phần mềm ra mắt trở nên quen thuộc, không còn cần đến các nghi thức phức tạp. Các nhóm có thể an tâm phát hành bất cứ khi nào cần mà không phải phụ thuộc vào sự phối hợp rườm rà hay những bước kiểm thử vào giai đoạn cuối. Tương tự như CI, để áp dụng CD hiệu quả, cần có sự kết hợp của cả các cải tiến về kỹ thuật và tổ chức.

Về mặt công nghệ, CD phụ thuộc rất nhiều vào các deployment pipeline để tự động hóa quy trình kiểm thử và triển khai. Một deployment pipeline là một hệ thống tự động chạy các bộ test (test suite) với độ nghiêm ngặt tăng dần trên một build qua một chuỗi các giai đoạn tuần tự. Quá trình này tiếp nối ngay tại điểm mà CI kết thúc, do đó, một nền tảng CI đủ độ ổn định và tin cậy là điều kiện tiên quyết để triển khai CD.

Ở mỗi giai đoạn, build có thể bị dừng lại nếu kiểm thử không đạt (lúc này, cảnh báo sẽ được gửi đến nhóm), hoặc được tiếp tục nếu vượt qua kiểm thử (và sẽ tự động chuyển sang giai đoạn kế tiếp). Khi build di chuyển qua toàn bộ pipeline, các giai đoạn sau sẽ triển khai nó lên những môi trường được thiết lập sao cho mô phỏng gần giống môi trường production nhất có thể. Cách tiếp cận này giúp đảm bảo rằng bản thân build, quy trình triển khai và môi trường chạy đều được kiểm thử đồng thời.

Kết thúc pipeline là một build đã sẵn sàng để được triển khai lên production bất cứ lúc nào, chỉ với một bước duy nhất.

Về mặt tổ chức, CD đề cao việc đặt “khả năng triển khai” (deployability) làm ưu tiên hàng đầu. Điều này ảnh hưởng đến cách các tính năng được xây dựng và tích hợp vào phần còn lại của codebase. Việc thiết kế code phải được cân nhắc kỹ lưỡng để các tính năng có thể được triển khai lên production một cách an toàn bất cứ lúc nào, ngay cả khi chúng chưa hoàn thiện. Nhiều kỹ thuật đã ra đời để hỗ trợ cho việc này.

Sức hấp dẫn của CD nằm ở chỗ nó tự động hóa các bước từ khi check-in code vào repository cho đến khi quyết định có nên phát hành các build đã được kiểm thử kỹ lưỡng và hoạt động tốt lên hạ tầng production hay không. Các bước giúp khẳng định chất lượng và tính đúng đắn của code đều được tự động hóa, nhưng quyết định cuối cùng về việc sẽ phát hành phiên bản nào vẫn thuộc về tổ chức để đảm bảo sự linh hoạt tối đa.

Vì sao Continuous deployment là bước tiến quan trọng sau CI và Delivery?

Continuous Deployment là bước phát triển tiếp theo của CD, trong đó mỗi bản build vượt qua toàn bộ chu trình kiểm thử sẽ được triển khai tự động lên môi trường production. Thay vì phải chờ một cá nhân có trách nhiệm ra quyết định về việc triển khai cái gì và khi nào, một hệ thống Continuous Deployment sẽ tự động đưa vào production mọi thay đổi đã vượt qua pipeline một cách thành công. Tuy nhiên, cần lưu ý rằng việc triển khai mã mới không đồng nghĩa với việc mọi tính năng mới sẽ được kích hoạt ngay lập tức. Các tính năng có thể được bật theo điều kiện, kích hoạt sau tại một thời điểm phù hợp, hoặc chỉ dành riêng cho một nhóm người dùng cụ thể.

Việc triển khai tự động giúp rút ngắn thời gian đưa các tính năng hoặc bản vá lỗi đến tay người dùng, đồng thời khuyến khích các thay đổi nhỏ, có phạm vi hạn chế, từ đó giảm thiểu rủi ro và tránh nhầm lẫn về nội dung đang chạy trên môi trường production.

Tuy nhiên, chu trình triển khai hoàn toàn tự động có thể khiến một số tổ chức lo ngại, đặc biệt là khi họ chưa sẵn sàng trao quyền kiểm soát việc phát hành cho hệ thống tự động. Trong những trường hợp này, cái giá của việc triển khai tự động đôi khi lớn hơn so với lợi ích mà nó mang lại.

Khi không có bước xác minh thủ công cuối cùng trước khi triển khai, lập trình viên phải tự chịu trách nhiệm đảm bảo code của mình được thiết kế tốt và các test suite luôn được cập nhật đầy đủ. Điều này hợp nhất các quyết định về việc commit và phát hành lại làm một; đối với team phát triển, quyết định commit code vào repository chính giờ đây cũng chính là quyết định phát hành sản phẩm lên production.

Không những vậy, Continuous Deployment còn giúp các tổ chức tận dụng hiệu quả việc nhận được phản hồi sớm và nhất quán. Các tính năng có thể được đưa đến tay người dùng gần như ngay lập tức, cho phép phát hiện kịp thời các lỗi hoặc tính năng không mang lại giá trị, trước khi nhóm phát triển đầu tư quá nhiều công sức vào một hướng đi thiếu hiệu quả. Khi phản hồi cho thấy một tính năng không thực sự cần thiết, nhóm có thể nhanh chóng điều chỉnh mục tiêu, thay vì tiếp tục tiêu tốn nguồn lực vào những phần ít tác động.

Các khái niệm và phương pháp cốt lõi trong các quy trình liên tục

Mặc dù CI, delivery và deployment khác nhau về phạm vi nhưng chúng đều có chung một số khái niệm và phương pháp nền tảng để đi đến thành công.

Thay đổi nhỏ và lặp lại

Một trong những phương pháp quan trọng nhất khi áp dụng CI là khuyến khích những thay đổi nhỏ. Lập trình viên nên tập cách chia nhỏ công việc thành các phần nhỏ và commit chúng từ sớm. Các kỹ thuật đặc biệt như branching by abstraction (phân nhánh bằng cách trừu tượng hóa) và feature flag (cờ tính năng) giúp bảo vệ chức năng của branch chính khỏi những thay đổi trong code đang được phát triển.

Những thay đổi nhỏ giúp giảm thiểu khả năng và tác động của các vấn đề tích hợp. Bằng cách commit vào branch chung ở giai đoạn sớm nhất có thể và sau đó tiếp tục commit liên tục trong suốt quá trình phát triển, chi phí tích hợp sẽ giảm đi và các phần công việc không liên quan được đồng bộ hóa thường xuyên.

Phát triển dựa trên Trunk (Trunk-Based Development)

Với Trunk-Based Development, công việc được thực hiện trực tiếp trên nhánh chính (“trunk”) của repository, hoặc thường xuyên được merge trở lại repository. Các feature branch tồn tại trong thời gian ngắn vẫn được chấp nhận, miễn là chúng đại diện cho các thay đổi nhỏ và được merge lại càng sớm càng tốt.

Ý tưởng cốt lõi của Trunk-Based Development là tránh các commit lớn, nhằm tuân thủ nguyên tắc thay đổi nhỏ và lặp lại đã đề cập ở phần trên. Code được chia sẻ với các thành viên khác càng sớm càng tốt, để các xung đột có thể được giải quyết khi chúng còn ở phạm vi nhỏ.

Việc release được thực hiện trực tiếp từ nhánh chính hoặc từ một nhánh phát hành (release branch) được tách ra từ trunk và dùng riêng cho mục đích phát hành. Không có hoạt động phát triển nào diễn ra trên các release branch, nhằm duy trì sự tập trung vào nhánh chính như một “nguồn chân lý duy nhất” (single source of truth).

Duy trì hiệu suất cao cho các giai đoạn xây dựng và kiểm thử

Mỗi quy trình này đều dựa trên việc build và test tự động để xác thực tính đúng đắn. Do các bước build và test cần được thực hiện thường xuyên nên điều cốt yếu là phải tối ưu hóa chúng nhằm giảm thiểu thời gian thực thi.

Thời gian build kéo dài là một vấn đề nghiêm trọng, vì tác động của nó sẽ nhân lên theo cấp số nhân, mỗi commit đều kích hoạt một lần build. Bởi quy trình liên tục yêu cầu lập trình viên tham gia vào các hoạt động này hàng ngày, nên việc loại bỏ những rào cản tại các khâu này là rất đáng giá.

Khi có thể, việc chạy song song các phần khác nhau trong test suite sẽ giúp build đi qua pipeline nhanh hơn. Đồng thời, cũng cần cẩn trọng trong việc cân bằng tỷ lệ giữa các loại test. Unit test thường rất nhanh và có chi phí bảo trì thấp; ngược lại, acceptance testing lại phức tạp và dễ phát sinh lỗi. Một cách tiếp cận hiệu quả là phụ thuộc chủ yếu vào unit test, thực hiện một lượng vừa phải các integration test và giới hạn tối đa số lượng các test phức tạp hơn.

Tính nhất quán trong toàn bộ quy trình triển khai

Vì việc triển khai CD hoặc Continuous Deployment nhằm kiểm tra mức độ sẵn sàng phát hành, nên điều cốt yếu là phải duy trì tính nhất quán trong mọi bước của quy trình – từ bản build, môi trường triển khai, đến chính quy trình triển khai:

• Code chỉ nên được build một lần ở đầu pipeline: Phần mềm sau khi được tạo ra cần được lưu trữ và sẵn sàng truy cập cho các bước kế tiếp mà không cần build lại. Việc sử dụng cùng một artifact xuyên suốt mọi giai đoạn giúp đảm bảo không phát sinh sai lệch do sự khác biệt giữa các công cụ hoặc quá trình build.
• Môi trường triển khai cần được tiêu chuẩn hóa: Hệ thống quản lý cấu hình (configuration management) có thể kiểm soát sự đồng nhất giữa các môi trường. Các thay đổi môi trường nên được đưa qua chính deployment pipeline để đảm bảo tính đúng đắn và kiểm soát được các khác biệt. Mỗi chu kỳ kiểm thử nên sử dụng một môi trường sạch để tránh các điều kiện còn sót lại làm sai lệch kết quả test. Môi trường staging cũng cần mô phỏng sát nhất môi trường production nhằm giảm thiểu những yếu tố bất định trước khi build được phát hành.
• Triển khai nhất quán ở mọi môi trường: Việc triển khai phải được tự động hóa hoàn toàn và sử dụng chung một công cụ, một quy trình tập trung. Các lần triển khai thủ công hoặc tùy hứng (ad-hoc) cần được loại bỏ, chỉ nên triển khai thông qua các công cụ thuộc pipeline.

Tách biệt Deployment khỏi Release

Tách quá trình triển khai mã khỏi thời điểm phát hành cho người dùng là một kỹ thuật cực kỳ hiệu quả của CD và Deployment. Code có thể được triển khai lên production mà ban đầu không kích hoạt hoặc không cho người dùng truy cập. Sau đó, tổ chức sẽ quyết định khi nào cần phát hành chức năng hoặc tính năng mới một cách độc lập với việc triển khai.

Điều này giúp các tổ chức đạt được mức độ linh hoạt cao, bằng cách tách biệt các quyết định kinh doanh khỏi các quy trình kỹ thuật. Khi mã nguồn đã có sẵn trên máy chủ, quá trình triển khai không còn là khâu nhạy cảm trong quy trình phát hành, từ đó giảm thiểu số lượng người cần tham gia cũng như khối lượng công việc tại thời điểm phát hành.

Có một số kỹ thuật cho phép team triển khai mã của một tính năng mà không cần phát hành ngay. Feature flag thiết lập điều kiện logic để xác định có nên kích hoạt đoạn mã hay không, dựa trên giá trị của một biến môi trường. Branching by abstraction tạo ra một lớp trừu tượng giữa đầu vào và đầu ra của một quy trình, cho phép lập trình viên dần thay thế hoặc chỉnh sửa logic bên trong mà không ảnh hưởng đến các thành phần còn lại. Với kế hoạch cẩn trọng, việc kết hợp các kỹ thuật này sẽ giúp tách biệt rõ ràng giữa triển khai và phát hành.

Các loại kiểm thử

CI, Delivery và Deployment đều đặt nền tảng trên kiểm thử tự động nhằm xác minh hiệu quả và tính chính xác của từng thay đổi trong mã nguồn. Việc áp dụng đa dạng các phương pháp kiểm thử trong suốt các quy trình này là điều thiết yếu để đảm bảo độ tin cậy của từng giải pháp kỹ thuật được đưa vào hệ thống.

Dù các phân loại dưới đây không phải là danh sách đầy đủ và vẫn còn nhiều quan điểm khác nhau về định nghĩa cụ thể của từng loại, chúng vẫn đại diện cho những cách tiếp cận kiểm thử phổ biến trong nhiều ngữ cảnh triển khai khác nhau.

Smoke Testing

Smoke test là một dạng kiểm thử sơ bộ đặc biệt, nhằm xác minh các chức năng cốt lõi cùng với một số giả định cơ bản liên quan đến triển khai và môi trường. Loại kiểm thử này thường nằm ở giai đoạn đầu của mỗi chu kỳ, đóng vai trò như một bước sàng lọc nhanh trước khi tiến hành kiểm thử toàn diện hơn.

Mục tiêu chính của smoke test là phát hiện sớm các lỗi nghiêm trọng có thể phát sinh trong quá trình triển khai, cũng như chỉ ra những vấn đề khiến cho các bước kiểm thử kế tiếp trở nên kém hiệu quả hoặc hoàn toàn vô nghĩa. Mặc dù phạm vi kiểm thử khá hạn chế, nhưng smoke test phải được thực hiện nhanh chóng và nhất quán. Một thay đổi không vượt qua được bước này thường là dấu hiệu cho thấy các giả định nền tảng đã bị phá vỡ, và việc tiếp tục kiểm thử khi chưa xử lý các lỗi đó là không hợp lý.

Tùy theo ngữ cảnh, smoke test có thể được áp dụng ở đầu mỗi giai đoạn kiểm thử mới nhằm xác nhận rằng các điều kiện và yêu cầu thiết yếu vẫn được đảm bảo. Ví dụ, trước khi tiến hành kiểm thử tích hợp hoặc triển khai lên máy chủ staging, nhóm phát triển có thể sử dụng smoke test để kiểm tra các yếu tố cốt lõi,mặc dù nội dung kiểm tra cụ thể trong từng trường hợp sẽ khác nhau.

Unit Testing

Unit test chịu trách nhiệm kiểm thử từng thành phần riêng biệt trong mã nguồn một cách cô lập, với mục tiêu rõ ràng. Chức năng của từng hàm hoặc lớp được đánh giá độc lập, không bị ảnh hưởng bởi các thành phần bên ngoài. Mọi phụ thuộc đều được thay thế bằng các phiên bản giả lập (như stub hoặc mock) để đảm bảo rằng bài kiểm thử chỉ tập trung vào đoạn mã đang được đánh giá.

Loại kiểm thử này giữ vai trò thiết yếu trong việc xác thực tính đúng đắn nội tại của từng đơn vị mã nguồn trước khi chúng được tích hợp vào những ngữ cảnh phức tạp hơn. Phạm vi hẹp và không có ràng buộc bên ngoài giúp dễ dàng khoanh vùng nguyên nhân gây lỗi khi phát sinh. Đây cũng là giai đoạn thuận lợi nhất để kiểm tra nhiều đầu vào và nhánh logic khác nhau – những trường hợp về sau có thể khó tái lập trong bối cảnh kiểm thử tích hợp.

Thông thường, unit test là một trong những bước đầu tiên được thực hiện sau mỗi thay đổi, kế tiếp sau smoke test. Các lập trình viên thường chạy chúng ngay trên máy trạm trước khi gửi mã lên hệ thống. Song song đó, các máy chủ CI cũng sẽ tự động chạy lại toàn bộ unit test như một cơ chế kiểm tra ban đầu, nhằm phát hiện sớm lỗi trước khi tiến hành các bước kiểm thử tiếp theo.

Integration Testing

Sau khi hoàn tất unit test, integration test được tiến hành bằng cách kết hợp nhiều thành phần lại thành một khối chức năng hợp nhất để kiểm tra hoạt động phối hợp giữa chúng. Nếu như unit test xác nhận chức năng của từng đơn vị mã khi tách biệt, thì integration test tập trung vào tính đúng đắn trong quá trình tương tác giữa các thành phần đó. Loại kiểm thử này có khả năng phát hiện một tập hợp lỗi hoàn toàn khác, phát sinh từ sự tương tác giữa các thành phần.

Thông thường, integration test được thực thi tự động khi mã được đẩy vào repository. Máy chủ CI sẽ lấy mã nguồn về, thực hiện các bước build cần thiết (thường bao gồm một smoke test nhanh để xác nhận build thành công), sau đó chạy unit test và integration test. Các module được kết nối theo các tổ hợp khác nhau và được kiểm thử.

Integration test đặc biệt quan trọng trong các dự án có nhiều người cùng phát triển, vì nó bảo vệ sự ổn định của dự án. Mọi thay đổi phải chứng minh rằng chúng không làm gián đoạn các chức năng hiện hữu và vẫn có thể tương tác đúng với các phần mã khác. Một mục tiêu quan trọng khác là đảm bảo rằng mã thay đổi có thể được triển khai thành công trong một môi trường sạch. Đây thường là chu kỳ kiểm thử đầu tiên không diễn ra trên máy của nhà phát triển, vì vậy các phụ thuộc phần mềm và môi trường chưa biết cũng có thể được phát hiện trong giai đoạn này. Đây cũng thường là lần đầu tiên mã mới được kiểm thử với các thư viện, dịch vụ và dữ liệu thực tế từ bên ngoài.

System Testing

Sau khi thực hiện Integration test, một cấp độ kiểm thử khác gọi là System test có thể bắt đầu. Ở nhiều khía cạnh, System test hoạt động như một phần mở rộng của kiểm thử tích hợp. Trọng tâm của System test là đảm bảo rằng các nhóm thành phần vận hành chính xác như một thể thống nhất.

Thay vì tập trung vào các giao diện giữa các thành phần, System test thường đánh giá chức năng bên ngoài của một phần mềm hoàn chỉnh. Tập hợp kiểm thử này bỏ qua các thành phần cấu thành bên trong để đánh giá phần mềm đã hợp nhất như một thực thể duy nhất. Do sự khác biệt này, System test thường tập trung vào các giao diện mà người dùng hoặc hệ thống bên ngoài có thể truy cập.

Acceptance Testing

Acceptance test là một trong những loại kiểm thử cuối cùng được thực hiện trên phần mềm trước khi bàn giao. Acceptance test được sử dụng để xác định liệu phần mềm có đáp ứng đầy đủ các yêu cầu từ góc nhìn của doanh nghiệp hoặc người dùng hay không. Các bài kiểm thử này đôi khi được xây dựng dựa trên đặc tả ban đầu và thường tập trung kiểm tra các giao diện để xác minh chức năng mong đợi cũng như mức độ dễ sử dụng.

Acceptance test thường là một giai đoạn kiểm thử chuyên sâu hơn và có thể kéo dài sau khi phần mềm đã được phát hành. Acceptance test tự động có thể được sử dụng để đảm bảo rằng các yêu cầu kỹ thuật trong thiết kế đã được đáp ứng, dù vậy xác minh thủ công cũng rất quan trọng.

Thông thường, acceptance test bắt đầu bằng cách triển khai bản build lên môi trường staging mô phỏng hệ thống production. Tại đây, các bộ kiểm thử tự động sẽ được chạy và người dùng nội bộ có thể truy cập vào hệ thống để xác minh xem phần mềm có hoạt động đúng như mong đợi hay không. Sau khi phát hành phần mềm hoặc cung cấp quyền truy cập beta cho người dùng, quá trình acceptance test tiếp tục diễn ra bằng cách đánh giá phần mềm trong điều kiện sử dụng thực tế và thu thập thêm phản hồi.

Thuật ngữ bổ sung

Bên cạnh các khái niệm tổng quát đã đề cập ở trên, còn rất nhiều khái niệm liên quan mà bạn có thể bắt gặp khi tìm hiểu về CI, delivery và deployment. Dưới đây là định nghĩa của một số thuật ngữ phổ biến:

• Blue-Green Deployment: Là một chiến lược để kiểm thử mã trong môi trường gần giống production và triển khai mã với thời gian gián đoạn tối thiểu. Hai bộ môi trường có khả năng chạy production được duy trì song song. Mã mới sẽ được triển khai vào bộ môi trường không hoạt động để kiểm thử. Khi sẵn sàng phát hành, lưu lượng truy cập production sẽ được chuyển sang các máy chủ chứa mã mới, khiến thay đổi có hiệu lực ngay lập tức.
• Branching by Abstraction: Là một kỹ thuật giúp thực hiện tái cấu trúc quy mô lớn trong một dự án đang vận hành mà không cần tạo ra các nhánh phát triển tồn tại lâu dài trong repository – điều vốn không được khuyến khích trong các thực hành CI. Kỹ thuật này tạo ra một lớp trừu tượng tích hợp vào phần triển khai hiện tại, từ đó cho phép xây dựng lại phần mới phía sau lớp trừu tượng một cách đồng thời với hệ thống đang hoạt động.
• Build (danh từ): Build là một phiên bản cụ thể của phần mềm được tạo từ mã nguồn. Tùy thuộc vào ngôn ngữ lập trình, build có thể là mã đã biên dịch hoặc một gói mã được chuẩn hóa để thông dịch.
• Canary Releases: Là một chiến lược phát hành thay đổi cho một nhóm người dùng giới hạn. Mục tiêu là đảm bảo hệ thống hoạt động đúng với tải thực tế của môi trường production trong khi vẫn hạn chế tác động nếu phát sinh sự cố.
• Dark Launch: Là kỹ thuật triển khai mã mới lên môi trường production nơi nó nhận được lưu lượng truy cập thực nhưng không ảnh hưởng đến trải nghiệm người dùng. Mã mới được triển khai song song với phần triển khai hiện tại và thường sử dụng cùng nguồn lưu lượng để kiểm thử. Giao diện người dùng vẫn kết nối với phần triển khai cũ, nhưng ở phía sau, mã mới được đánh giá về tính chính xác dựa trên các truy vấn thực từ người dùng.
• Deployment Pipeline: Là một chuỗi các bước giúp đưa phần mềm đi qua nhiều giai đoạn kiểm thử và triển khai ngày càng nghiêm ngặt, nhằm đánh giá xem phần mềm đã đủ điều kiện để phát hành hay chưa. Pipeline thường kết thúc bằng việc tự động triển khai lên môi trường production hoặc cho phép thực hiện thủ công nếu cần.
• Feature Flags hoặc Feature Toggles: Feature flag là kỹ thuật triển khai tính năng mới phía sau lớp logic điều kiện dựa trên giá trị của biến môi trường để quyết định có chạy hay không. Mã mới có thể được triển khai lên production mà không được kích hoạt nếu cờ kiểm soát được thiết lập phù hợp. Feature flag thường bao gồm logic cho phép một phần người dùng truy cập vào tính năng mới, tạo điều kiện để triển khai mã dần dần.
• Promoting: Trong bối cảnh của các quy trình liên tục, promoting là hành động chuyển một build phần mềm sang giai đoạn kiểm thử tiếp theo.
• Soak Test: Là hình thức kiểm thử phần mềm dưới tải tương đương hoặc gần giống môi trường production trong một khoảng thời gian dài.

Kết luận

Trong bài viết này, chúng ta đã giới thiệu về CI, CD và Continuous Deployment, đồng thời thảo luận cách sử dụng để xây dựng và phát hành phần mềm đã được kiểm thử kỹ lưỡng một cách an toàn và nhanh chóng.

Các quy trình này tận dụng triệt để khả năng tự động hóa và khuyến khích việc chia sẻ mã nguồn một cách liên tục nhằm phát hiện và khắc phục lỗi từ sớm. Dù việc triển khai các giải pháp này đòi hỏi phải đầu tư đáng kể vào kỹ thuật, quy trình và công cụ nhưng nếu hệ thống được thiết kế đúng và vận hành hiệu quả, lợi ích mang lại sẽ rất lớn.