Phân Phối Liên Tục

Nó nhằm mục đích build, kiểm thử, và phát hành phần mềm nhanh hơn và thường xuyên hơn. Cách tiếp cận này giúp giảm chi phí, thời gian và nguy cơ khi thay đổi bằng cách gia tăng cập nhật các ứng dụng trong sản phảm. Một quá trình triển khai đơn giản và lặp lại là điều quan trọng cho Phân phối liên tục (CD).

CD và DevOps tương tự nhau như ở mặt ý nghĩa của chúng, và thường bị hòa trộn vào nhau, nhưng chúng là hai khái niệm khác nhau. DevOps có phạm vi rộng hơn và xoay quanh thay đổi văn hóa, đặc biệt là sự hợp tác của các đội khác nhau khi tham gia vào làm phần mềm (nhà phát triển, nhà điều hành, QA,...) cũng như việc tự động hóa quá trình phân phối phần mềm. CD mặt khác, là một cách tiếp cận để tự động hóa khía cạnh phân phối, và tập trung vào việc mang các quá trình lại với nhau để thực hiện chúng nhanh hơn và thường xuyên hơn. Như vậy, DevOps có thể là một sản phẩm của CD, và CD đi trực tiếp vào DevOps.

Phân phối liên tục đôi khi bị nhầm lẫn với Triển khai liên tục. Triển khai liên tục có nghĩa là mọi thay đổi được triển khai tự động lên sản phẩm. Phân phối liên tục có nghĩa là đội làm việc đảm bảo rằng mọi thay đổi có thể được triển khai lên sản phẩm, nhưng cũng có thể không cần phải triển khai, thường do lý do kinh doanh. Để làm được Triển khai liên tục người ta phải làm được cả Phân phối liên tục.

Phân phối liên tục xử lý các khái niệm phổ biến của đường ống triển khai (deployment pipeline) như là một Poka-Yoke tinh giản: một bộ kiểm chứng thực mà qua đó một phần mềm phải vượt qua trước để có thể phát hành. Mã nguồn được tổng hợp nếu cần thiết, và sau đó đóng gói bởi một máy build mỗi lần thay đổi được commit vào nguồn kiểm soát kho lưu trữ, sau đó kiểm thử bởi một số của các kỹ thuật khác nhau (có thể, bao gồm cả kiểm thử thủ công) trước khi nó được đánh dấu đủ tiêu chuẩn phát hành.

Phân phối liên tục được kích hoạt thông qua đường ống triển khai (deployment pipeline). Mục đích của đường ống triển khai  gồm ba thành phần: sự khả thị, phản hồi, và triển khai liên tục.

• Sự khả thị (visibility) – tất cả các hệ thống cung cấp bao gồm cả build, triển khai, kiểm thử, và phát hành phải được nhìn thấy bởi mọi thành viên của đội để thúc đẩy hợp tác.
• Phản hồi (feedback) – thành viên trong đội tìm hiểu vấn đề càng sớm càng tốt khi chúng xảy ra vì vậy mà họ có thể sửa chữa chúng càng nhanh càng tốt.
• Triển khai liên tục (CD) – Qua một quá trình tự động, bạn có thể triển khai và phát hành phiên bản bất kỳ nào của phần mềm trên bất kỳ môi trường nào.

Phân phối liên tục giúp tự động quá trình từ mã nguồn tới sản phẩm. Có rất nhiều công cụ giúp thực hiện tất cả hay một phần trong quá trình này. Những công cụ này là một phần của đường ống triển khai, trong đó bao gồm Phân phối liên tục. Các loại công cụ thực thi các phần khác nhau của quá trình bao gồm: Tích hợp liên tục, tự động phát hành ứng dụng, tự động build, quản lý vòng đời ứng dụng.

Để thực hành CD một cách hiệu quả, phần mềm phải đáp ứng một tập hợp các Yêu cầu đặc biệt có tính kiến trúc (Architecturally Significant Requirements - ASRs) như Triển khai được, Sửa được, và Kiểm thử được. Những ASRs yêu cầu sự ưu tiên hàng đầu và không được xem nhẹ.

Các sách về CD của Jez Humble và David Farley khá phổ biến. Các công ty ngày nay thực hiện các nguyên tắc và mô hình mẫu của CD. Sự khác biệt trong lĩnh vực, ví dụ như dược và web, vẫn còn quan trọng và ảnh hưởng đến việc thực hiện và sử dụng CD. Các công ty nổi tiếng có cách tiếp cận này bao gồm Yahoo.com Amazon.com,^{[cần dẫn nguồn]} Facebook,^{[cần dẫn nguồn]} Google, Paddy Power và Wells Fargo.

Nhiều lợi ích của CD đã được báo cáo.

• Tăng tốc thời gian đưa sản phẩm ra thị trường
• Build đúng sản phẩm theo yêu cầu của thị trường
• Cải thiện năng suất và hiệu quả: tiết kiệm thời gian phát triển, thử nghiệm phần mềm thông qua sự tự động hóa.
• Phát hành đáng tin cậy
• Cải thiện chất lượng sản phẩm
• Cải thiện sự hài lòng của khách hàng

Trở ngại vật cũng được đưa ra.

• Sở thích của khách hàng: Một số khách hàng không muốn liên tục cập nhật hệ thống của họ, đặc biệt ở các giai đoạn quan trọng trong hoạt động của họ.
• Lĩnh vực hạn chế: trong một số lĩnh vực chẳng hạn như viễn thông và y tế, yêu cầu phải thử nghiệm sản phẩm rộng rãi trước khi phiên bản mới được phép đưa vào hoạt động.
• Thiếu kiểm thử tự động
• Môi trường khác nhau: môi trường được sử dụng trong phát triển, thử nghiệm và sản xuất khác nhau có thể dẫn đến các vấn đề về sau.
• Kiểm thử cần sự can thiệp của con người: Không phải tất cả thuộc tính có thể được kiểm thử tự động. Những bước đòi hỏi phải có con người can thiệp làm chậm đường ống phân phối (delivery pipeline).

• Lập trình cực hạn
• Lập trình linh hoạt
• Tích hợp liên tục
• Kiểm thử liên tục
• DevOps
• Hệ thống quản lý phiên bản
• Quản lý vòng đời ứng dụng
• Tự động phát hành ứng dụng
• Quản lý build
• Quản lý thay đổi
• Tự động cấu hình liên tục
• Quản lý phát hành
• Quản lý cấu hình phần mềm
• WinOps

• Humble, Jez; Farley, David (2010). Continuous Delivery: Reliable Software Releases Through Build, Test and Deployment Automation. Addison-Wesley. ISBN 978-0-321-60191-9.