Làm thế nào có thể giao hàng liên tục làm việc trong thực tế?

Giao hàng liên tục nghe có vẻ tốt, nhưng kinh nghiệm phát triển phần mềm nhiều năm của tôi cho thấy rằng trong thực tế, nó không thể hoạt động.

(Chỉnh sửa: Để làm rõ, tôi luôn có rất nhiều bài kiểm tra chạy tự động. Câu hỏi của tôi là làm thế nào để có được sự tự tin để cung cấp cho mỗi lần đăng ký, mà tôi hiểu là dạng CD đầy đủ. Đó là các lần lặp lại mỗi tuần (mà một số người có thể xem xét vẫn là CD nếu được thực hiện chính xác), hai tuần hoặc tháng; bao gồm cả QA lỗi thời ở cuối mỗi bài, bổ sung các bài kiểm tra tự động.)

• Bảo hiểm thử nghiệm đầy đủ là không thể. Bạn phải dành nhiều thời gian - và thời gian là tiền bạc - cho mọi thứ nhỏ nhặt. Điều này là có giá trị, nhưng thời gian có thể được dành để đóng góp cho chất lượng theo những cách khác.
• Một số thứ khó kiểm tra tự động. Ví dụ: GUI. Ngay cả Selenium cũng sẽ không cho bạn biết GUI của bạn có mạnh không. Truy cập cơ sở dữ liệu rất khó kiểm tra nếu không có đồ đạc cồng kềnh và thậm chí sẽ không bao gồm các trường hợp góc lạ trong bộ lưu trữ dữ liệu của bạn. Tương tự như vậy an ninh và nhiều thứ khác. Chỉ có mã lớp doanh nghiệp là có thể kiểm tra đơn vị một cách hiệu quả.
• Ngay cả trong lớp nghiệp vụ, hầu hết các mã ngoài đó không có các hàm đơn giản mà các đối số và giá trị trả về có thể dễ dàng bị cô lập cho các mục đích thử nghiệm. Bạn có thể dành nhiều thời gian để xây dựng các đối tượng giả, có thể không tương ứng với việc triển khai thực tế.
• Các thử nghiệm tích hợp / chức năng bổ sung cho các thử nghiệm đơn vị, nhưng các thử nghiệm này mất rất nhiều thời gian để chạy vì chúng thường liên quan đến việc khởi tạo lại toàn bộ hệ thống trên mỗi thử nghiệm. (Nếu bạn không khởi tạo lại, môi trường kiểm tra không nhất quán.)
• Tái cấu trúc hoặc bất kỳ thay đổi nào khác phá vỡ rất nhiều bài kiểm tra. Bạn dành nhiều thời gian để sửa chúng. Nếu đó là vấn đề xác nhận các thay đổi thông số có ý nghĩa, thì tốt, nhưng thường kiểm tra bị hỏng vì các chi tiết triển khai cấp thấp vô nghĩa, không phải là thứ thực sự cung cấp thông tin quan trọng. Thông thường việc tinh chỉnh được tập trung vào việc làm lại các phần bên trong của bài kiểm tra, chứ không phải thực sự kiểm tra chức năng đang được kiểm tra.
• Báo cáo thực địa về các lỗi không thể dễ dàng được khớp với phiên bản vi mô chính xác của mã.

kinh nghiệm phát triển phần mềm nhiều năm của tôi cho thấy rằng trong thực tế, nó không thể hoạt động.

Bạn đã thử chưa? Dave và tôi đã viết cuốn sách dựa trên nhiều năm kinh nghiệm tập thể, cả bản thân chúng tôi và những người cao cấp khác trong Th ThinkWorks, thực sự đang làm những điều chúng ta thảo luận. Không có gì trong cuốn sách là đầu cơ. Tất cả mọi thứ chúng tôi thảo luận đã được thử và kiểm tra ngay cả trên các dự án lớn, phân tán. Nhưng chúng tôi không khuyên bạn nên tin vào điều đó. Tất nhiên, bạn nên tự mình thử nó, và vui lòng viết ra những gì bạn tìm thấy hoạt động và những gì không, bao gồm bối cảnh có liên quan, để những người khác có thể học hỏi từ kinh nghiệm của bạn.

Giao hàng liên tục tập trung lớn vào thử nghiệm tự động. Chúng tôi dành khoảng 1/3 cuốn sách nói về nó. Chúng tôi làm điều này bởi vì giải pháp thay thế - kiểm tra thủ công - rất tốn kém và dễ bị lỗi, và thực sự không phải là cách tuyệt vời để xây dựng phần mềm chất lượng cao (như Deming nói, "Ngừng phụ thuộc vào kiểm tra hàng loạt để đạt được chất lượng. Cải thiện quy trình và xây dựng chất lượng thành sản phẩm ở nơi đầu tiên ")

Bảo hiểm thử nghiệm đầy đủ là không thể. Bạn phải dành nhiều thời gian - và thời gian là tiền bạc - cho mọi thứ nhỏ nhặt. Điều này là có giá trị, nhưng thời gian có thể được dành để đóng góp cho chất lượng theo những cách khác.

Tất nhiên phạm vi kiểm tra đầy đủ là không thể, nhưng điều gì thay thế: bảo hiểm kiểm tra không? Có một sự đánh đổi. Một nơi nào đó ở giữa là câu trả lời chính xác cho dự án của bạn. Chúng tôi thấy rằng nói chung, bạn nên dành khoảng 50% thời gian để tạo hoặc duy trì các bài kiểm tra tự động. Điều đó có vẻ tốn kém cho đến khi bạn xem xét chi phí kiểm tra thủ công toàn diện và sửa các lỗi phát sinh cho người dùng.

Một số thứ khó kiểm tra tự động. Ví dụ: GUI. Ngay cả Selenium cũng sẽ không cho bạn biết GUI của bạn có mạnh không.

Tất nhiên. Kiểm tra góc phần tư thử nghiệm của Brian Marick. Bạn vẫn cần phải thực hiện kiểm tra thăm dò và kiểm tra khả năng sử dụng bằng tay. Nhưng đó là những gì bạn nên sử dụng con người đắt tiền và có giá trị của mình - không phải kiểm tra hồi quy. Điều quan trọng là bạn cần đặt một đường ống triển khai để bạn chỉ cần chạy các xác nhận thủ công đắt tiền đối với các bản dựng đã vượt qua một bộ kiểm tra tự động toàn diện. Do đó, cả hai bạn đều giảm số tiền bạn bỏ ra để kiểm tra thủ công và số lỗi đã xảy ra để kiểm tra thủ công hoặc sản xuất (vào thời điểm đó chúng rất tốn kém để khắc phục). Thử nghiệm tự động được thực hiện đúng là rẻ hơn nhiều so với vòng đời của sản phẩm, nhưng tất nhiên đó là chi phí vốn tự khấu hao theo thời gian.

Truy cập cơ sở dữ liệu rất khó kiểm tra nếu không có đồ đạc cồng kềnh và thậm chí sẽ không bao gồm các trường hợp góc lạ trong bộ lưu trữ dữ liệu của bạn. Tương tự như vậy an ninh và nhiều thứ khác. Chỉ có mã lớp doanh nghiệp là có thể kiểm tra đơn vị một cách hiệu quả.

Truy cập cơ sở dữ liệu được kiểm tra ngầm bằng các thử nghiệm chấp nhận chức năng dựa trên kịch bản từ đầu đến cuối của bạn. Bảo mật sẽ yêu cầu kết hợp kiểm tra tự động và thủ công - kiểm tra thâm nhập tự động và phân tích tĩnh để tìm (ví dụ) tràn bộ đệm.

Ngay cả trong lớp nghiệp vụ, hầu hết các mã ngoài đó không có các hàm đơn giản mà các đối số và giá trị trả về có thể dễ dàng bị cô lập cho các mục đích thử nghiệm. Bạn có thể dành nhiều thời gian để xây dựng các đối tượng giả, có thể không tương ứng với việc triển khai thực tế.

Tất nhiên các bài kiểm tra tự động rất tốn kém nếu bạn xây dựng phần mềm và các bài kiểm tra của bạn không tốt. Tôi đặc biệt khuyên bạn nên kiểm tra cuốn sách "phát triển phần mềm hướng đối tượng, được hướng dẫn bởi các bài kiểm tra" để hiểu cách thực hiện đúng để các bài kiểm tra và mã của bạn được duy trì theo thời gian.

Các thử nghiệm tích hợp / chức năng bổ sung cho các thử nghiệm đơn vị, nhưng các thử nghiệm này mất rất nhiều thời gian để chạy vì chúng thường liên quan đến việc khởi tạo lại toàn bộ hệ thống trên mỗi thử nghiệm. (Nếu bạn không khởi tạo lại, môi trường kiểm tra không nhất quán.)

Một trong những sản phẩm tôi từng làm việc có bộ 3.500 bài kiểm tra chấp nhận từ đầu đến cuối phải mất 18 giờ để chạy. Chúng tôi chạy song song trên lưới 70 ô và nhận phản hồi trong 45m. Vẫn còn dài hơn lý tưởng, đó là lý do tại sao chúng tôi chạy nó như là giai đoạn thứ hai trong đường ống sau khi các bài kiểm tra đơn vị đã chạy trong vài phút để chúng tôi không lãng phí tài nguyên của mình vào một bản dựng mà chúng tôi không có mức độ cơ bản tự tin vào

Tái cấu trúc hoặc bất kỳ thay đổi nào khác phá vỡ rất nhiều bài kiểm tra. Bạn dành nhiều thời gian để sửa chúng. Nếu đó là vấn đề xác nhận các thay đổi thông số có ý nghĩa, thì tốt, nhưng thường kiểm tra bị hỏng vì các chi tiết triển khai cấp thấp vô nghĩa, không phải là thứ thực sự cung cấp thông tin quan trọng. Thông thường việc tinh chỉnh được tập trung vào việc làm lại các phần bên trong của bài kiểm tra, chứ không phải thực sự kiểm tra chức năng đang được kiểm tra.

Nếu mã và kiểm tra của bạn được đóng gói tốt và được ghép lỏng lẻo, tái cấu trúc sẽ không phá vỡ nhiều thử nghiệm. Chúng tôi mô tả trong cuốn sách của chúng tôi làm thế nào để làm điều tương tự cho các bài kiểm tra chức năng quá. Nếu các bài kiểm tra chấp nhận của bạn bị hỏng, đó là dấu hiệu bạn thiếu một hoặc nhiều bài kiểm tra đơn vị, do đó, một phần của CD liên quan đến việc liên tục cải thiện phạm vi kiểm tra của bạn để thử và tìm lỗi sớm hơn trong quy trình phân phối trong đó các bài kiểm tra chi tiết hơn và lỗi rẻ hơn để sửa chữa.

Báo cáo thực địa về các lỗi không thể dễ dàng được khớp với phiên bản vi mô chính xác của mã.

Nếu bạn đang kiểm tra và phát hành thường xuyên hơn (một phần của điểm CD) thì việc xác định thay đổi gây ra lỗi là tương đối đơn giản. Toàn bộ quan điểm của CD là tối ưu hóa chu kỳ phản hồi để bạn có thể xác định lỗi càng sớm càng tốt sau khi chúng được kiểm tra để kiểm soát phiên bản - và thực tế, tốt nhất là trước khi chúng được kiểm tra (đó là lý do tại sao chúng tôi chạy thử nghiệm bản dựng và đơn vị trước khi nhận phòng).

Đầu tiên, CD cần một sự điều chỉnh lớn về mặt tinh thần - bạn phải thừa nhận rằng đôi khi mọi thứ sẽ bị phá vỡ bất kể bạn làm gì. Vào cuối ngày, bạn không thể chứng minh điều tiêu cực.

Khi bạn vượt qua điều này, bạn nhận ra rằng bạn cần các công cụ và quy trình để a) nắm bắt các lỗi này rất nhanh và b) quay lại hoặc triển khai bản cập nhật rất hiệu quả. Hơn nữa, nếu bạn thực sự uống cocktail CD, bạn thực sự đang cung cấp rất nhiều thay đổi nhỏ, nhọn, dễ dàng quay trở lại và không thể đưa ra các lỗi lớn, toàn ứng dụng. Ngay cả những anh chàng thực sự thực hành CD cũng đang xử lý những thay đổi lớn theo cách truyền thống hơn.

Mọi hệ thống đều có rủi ro, và mọi rủi ro đều có chi phí tiềm năng. Nếu chi phí của một số rủi ro nhỏ, loại có thể mất nhiều tháng hoặc nhiều năm để tìm kiếm trong thử nghiệm rộng rãi và QA, là đủ cao (phần mềm trong máy điều hòa nhịp tim của bạn), bạn không giao hàng mà không có thời gian thử nghiệm rộng rãi phát hành đông lạnh. Nếu chi phí thất bại đủ nhỏ, có thể bạn giao hàng liên tục với thử nghiệm bằng không (trang Facebook của con mèo của bạn).

Bảo hiểm thử nghiệm đầy đủ là không thể. Bạn phải dành nhiều thời gian - và thời gian là tiền bạc - cho mọi thứ nhỏ nhặt. Điều này là có giá trị, nhưng thời gian có thể được dành để đóng góp cho chất lượng theo những cách khác.

Bạn không cần bảo hiểm 100%, bạn cần đủ tự tin vào hệ thống của mình, việc thay đổi ở một nơi sẽ không phá vỡ những điều bạn đã chứng minh trước đây.

Một số thứ khó kiểm tra tự động. Ví dụ: GUI. Ngay cả Selenium cũng sẽ không
cho bạn biết GUI của bạn có mạnh không. Truy cập cơ sở dữ liệu rất khó kiểm tra nếu không có đồ đạc cồng kềnh và thậm chí sẽ không bao gồm các trường hợp góc lạ trong bộ lưu trữ dữ liệu của bạn.

Cơ sở dữ liệu truy cập là tầm thường để viết tuy nhiên. Bạn không cần nhiều thử nghiệm trên lớp dữ liệu của mình vì nó chỉ nhận và thiết lập dữ liệu. Điều quan trọng nhất là đảm bảo rằng khi nó bị lỗi, nó sẽ khôi phục và ghi lại sự cố để bạn có thể khắc phục nó.

Tương tự như vậy an ninh và nhiều thứ khác. Chỉ có mã lớp doanh nghiệp là có thể kiểm tra đơn vị một cách hiệu quả. Ngay cả trong lớp nghiệp vụ, hầu hết các mã ngoài đó không có các hàm đơn giản mà các đối số và giá trị trả về có thể dễ dàng bị cô lập cho các mục đích thử nghiệm.

Sau đó, nhiều chức năng / lớp học của bạn quá lớn. Chúng nên được viết để có thể kiểm tra.

Bạn có thể dành nhiều thời gian để xây dựng các đối tượng giả, có thể không tương ứng với việc triển khai thực tế.

Tuy nhiên, I / O của đối tượng giả phải khớp với những gì được mong đợi. Những gì xảy ra bên trong nó không quan trọng.

Các thử nghiệm tích hợp / chức năng bổ sung cho các thử nghiệm đơn vị, nhưng các thử nghiệm này mất rất nhiều thời gian để chạy vì chúng thường liên quan đến việc khởi tạo lại toàn bộ hệ thống trên mỗi thử nghiệm. (Nếu bạn không khởi tạo lại, môi trường kiểm tra không nhất quán.)

Chúng không nên chạy mọi lúc. Chỉ cần khi cần.

Tái cấu trúc hoặc bất kỳ thay đổi nào khác phá vỡ rất nhiều bài kiểm tra. Bạn dành nhiều thời gian để sửa chúng. Nếu đó là vấn đề xác nhận các thay đổi thông số có ý nghĩa, thì tốt, nhưng thường kiểm tra bị hỏng vì các chi tiết triển khai cấp thấp vô nghĩa, không phải là thứ thực sự cung cấp thông tin quan trọng. Thông thường việc tinh chỉnh được tập trung vào việc làm lại các phần bên trong của bài kiểm tra, chứ không phải thực sự kiểm tra chức năng đang được kiểm tra.

Sau đó, mã của bạn được ghép quá chặt chẽ và các bài kiểm tra của bạn được viết kém.

Báo cáo thực địa về các lỗi không thể dễ dàng được khớp với phiên bản vi mô chính xác của mã.

Không chắc chắn những gì bạn đang nhận được ở đây? Nếu có lỗi, hãy viết một bài kiểm tra để cho thấy sự tồn tại của nó, sau đó sửa nó.

Hoạt động tốt cho chúng tôi, nhưng khách hàng của chúng tôi chủ yếu là nội bộ. Nhiều bản dựng được thực hiện trong ngày, các bản dựng bị hỏng không được dung thứ, cơ chế khởi động web được sử dụng để người dùng có được phiên bản mới nhất mỗi lần ra mắt. Một điều là CD làm cho rất nhiều vấn đề biến mất. Có, bạn luôn có mối quan tâm về khả năng tương thích, tuy nhiên, vì bạn chỉ triển khai các thay đổi nhỏ mỗi lần, nên mối quan tâm thực sự dễ dàng được xử lý. Mức độ căng thẳng của CD thấp hơn nhiều so với khi chúng tôi thực hiện các bản cập nhật lớn và phải hy vọng rằng mọi thứ đều ổn vì có quá nhiều mã để xem xét trong trường hợp bị hỏng.

Thành thật mà nói, TẤT CẢ phần mềm đang được phân phối liên tục! Điều quan trọng nhất là đưa nó ra khỏi cửa! Nhận người dùng của bạn sử dụng nó và ưu tiên các yêu cầu tính năng và sửa lỗi sau đó.

"Tàu nghệ sĩ thực sự"
- Steve Jobs.