Phân phối liên tục

Phân phối liên tục (tiếng Anh: Continuous delivery - viết tắt: CD) là một cách tiếp cận của kỹ thuật phần mềm, trong đó các đội sẽ sản xuất phần mềm trong chu kỳ ngắn, đảm bảo rằng các phần mềm có thể được phát hành một cách tin cậy bất cứ lúc nào.^[1] 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).

Mối quan hệ với DevOps

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.^[2] DevOps có phạm vi rộng hơn^[3] 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.^[3] 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.^[4] 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.

Mối quan hệ với Triển khai liên tục (Continuous deployment)

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.^[5]

Nguyê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:^[6] 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.

Đường ống triển khai (Deployment pipeline)

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.^[7]

• 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.

Công cụ và loại công cụ

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.^[7] 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.^[7]

Kiến trúc của Phân phối liên tục

Để 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ẹ.

Thực hiện và sử dụng

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^[8] Amazon.com,^{[cần dẫn nguồn]} Facebook,^{[cần dẫn nguồn]} Google,^[9] Paddy Power và Wells Fargo.^[10]

Lợi ích và trở ngại

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

• 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).

Xem thêm

• 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

Đọc thêm

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

Tham khảo

1. Chen, Lianping (2015). “Continuous Delivery: Huge Benefits, but Challenges Too”. IEEE Software. 32 (2): 50. doi:10.1109/MS.2015.27.
2. Hammond, Jeffrey (ngày 9 tháng 9 năm 2011). “The Relationship between DevOps and Continuous Delivery”. Forrester Research. Forester.
3. ^ Humble, Jez; Farley, David (2011). Continuous Delivery: reliable software releases through build, test, and deployment automation. Pearson Education Inc. ISBN 978-0-321-60191-9.
4. Swartout, Paul (2012). Continuous Delivery and DevOps: A Quickstart guide. Packt Publishing. ISBN 978-1849693684.
5. “bliki: ContinuousDelivery”. martinfowler.com. Truy cập ngày 29 tháng 10 năm 2015.
6. Lỗi chú thích: Thẻ <ref> sai; không có nội dung trong thẻ ref có tên ArchCD_LC
7. ^ Lỗi chú thích: Thẻ <ref> sai; không có nội dung trong thẻ ref có tên Chú thích tạp chí
8. “Implementing Continuous Delivery at Yahoo!”. confreaks.tv. ngày 23 tháng 10 năm 2013. Bản gốc lưu trữ ngày 17 tháng 7 năm 2015. Truy cập ngày 23 tháng 2 năm 2017.
9. Humble, Jez (ngày 13 tháng 2 năm 2014). “The Case for Continuous Delivery”. thoughtworks.com. Truy cập ngày 16 tháng 7 năm 2014.
10. jFrog (tháng 12 năm 2014). “2014-year-continuous-integration-revolution”.
11. Leppänen, M.; Mäkinen, S.; Pagels, M.; Eloranta, V. P.; Itkonen, J.; Mäntylä, M. V.; Männistö, T. (ngày 1 tháng 3 năm 2015). “The Highways and Country Roads to Continuous Deployment”. IEEE Software. 32 (2): 64–72. doi:10.1109/MS.2015.50. ISSN 0740-7459.