Các lỗi "tinh tế" được tìm thấy trong sản xuất không được xác định trên môi trường dàn dựng - trong một trong những dự án có vấn đề như vậy tôi đã thấy điều này được giải quyết khá thành công bằng chiến thuật mà tôi gọi là vấn đề kép. Ý tôi là đối với các lỗi như vậy, mọi người đã tạo ra hai vé trong trình theo dõi vấn đề: một được giao cho các nhà phát triển để sửa mã, một cho người kiểm tra để thiết kế và thiết lập kiểm tra hồi quy hoặc thay đổi trong môi trường dàn dựng sẽ ngăn việc lặp lại trong tương lai. Điều đó đã giúp giữ cho dàn dựng đủ gần để prod.
các vấn đề trên môi trường sản xuất đòi hỏi phải quay lại - nếu những điều này xảy ra thường xuyên thì các bản phát hành hàng tuần của bạn thực sự là giả - hãy xem xét điều chỉnh tần suất theo mức thực sự hoạt động. Bằng giả, tôi có nghĩa là nếu nói một trong hai bản phát hành hàng tuần của bạn quay lại thì có nghĩa là người dùng phải đối mặt với bản phát hành mới (làm việc) một lần trong hai tuần - đó là tất cả những gì được tính, không phải số lần bạn triển khai.
Các nhánh tính năng được thi hành nhiệt tình - điều đó có nghĩa là một thời gian trước đó, bạn cũng đã thử làm việc trên một nhánh duy nhất và thấy nó kém hơn? Nếu có thì bỏ qua phần còn lại. Nếu không, hãy thử làm việc trên một nhánh duy nhất (nếu cần, google cho chiến lược phân nhánh "nhánh phát triển" hoặc chiến lược phân nhánh "thân cây không ổn định" để biết chi tiết). Hoặc, nếu bạn sử dụng Perforce, hãy tìm kiếm trên web các hướng dẫn của Microsoft về phân nhánh và hợp nhất. Hãy thử tôi đã nói điều đó? Xin lỗi, từ thích hợp nên được kiểm tra : Ý tôi là, 1) lập kế hoạch khi nào và làm thế nào để đo xem một nhánh duy nhất có tốt hơn hay không so với một nhánh bạn có bây giờ và 2) lập kế hoạch khi nào và làm thế nào bạn sẽ chuyển trở lại các nhánh tính năng trong trường hợp này thử nghiệm thất bại .
Tái bút
Có lẽ bạn có thể tìm thấy nhiều thủ thuật như vậy bằng cách tìm kiếm trên web cho một cái gì đó như quản lý rủi ro dự án phần mềm
cập nhật
<sao chép từ ý kiến>
Tôi nhận thấy các bản sửa lỗi nóng thường xuyên là một triệu chứng của đường ống thử nghiệm bị hỏng - đây có phải là trường hợp không? Dù bằng cách nào, họ yêu cầu các bản phát hành lặp đi lặp lại để có được các bản sửa lỗi nóng để tạo ra nhiều công việc hơn cho nhóm ops. Ngoài ra, các bản sửa lỗi nóng thường được mã hóa dưới áp lực thời gian cực lớn, có nghĩa là chúng có thể sẽ có chất lượng thấp hơn so với công việc bình thường.
</ sao chép từ ý kiến>
- bản sửa lỗi nóng vào phút cuối - những lo ngại trên có vẻ hợp lý với tôi, cũng như tài liệu tham khảo của bạn về đường ống thử nghiệm bị hỏng. Với bản cập nhật này, lưu ý trước đó của bạn rằng tích hợp mã mới bị chặn vào thứ Hai nghe có vẻ như là một triệu chứng bị hỏng (tôi nghĩ rằng từ chính xác hơn sẽ được dự kiến ). Theo tranh luận, ý tôi là như sau: bạn sử dụng một nhánh duy nhất để phục vụ đồng thời hai mục đích: tích hợp và phát hành. Khi phát hành tiếp cận, hai mục đích này bắt đầu đụng độ với nhau, thúc đẩy các yêu cầu mâu thuẫn: mục đích tích hợp được phục vụ tốt nhất với chi nhánh mở liên tục ( Hợp nhất sớm và thường ) trong khi giải phóng lợi ích ổn định từ chi nhánh được niêm phong (cách ly) càng lâu càng tốt. A-ha có vẻ như các phần câu đố bắt đầu nhận được phù hợp ...
..Look, việc đóng băng vào Thứ Hai bây giờ có vẻ như là một sự thỏa hiệp được thực hiện để phục vụ các mục đích xung đột: các nhà phát triển chịu sự tích hợp của mã mới trong khi những người thử nghiệm chịu đựng khối này quá ngắn gọn, mọi người đều có phần không hài lòng nhưng cả hai mục đích đều được phục vụ ít nhiều.
Bạn biết đấy, được đưa ra ở trên tôi nghĩ rằng đặt cược tốt nhất của bạn sẽ là thử phát hành từ chi nhánh chuyên dụng (ngoài tích hợp) . Cho dù chi nhánh này sẽ tồn tại lâu như tích hợp hay tồn tại ngắn như các nhánh tính năng của bạn (với "tính năng", tốt, phát hành) - tùy thuộc vào bạn, nó chỉ cần tách biệt.
Chỉ cần nghĩ về nó. Hiện tại bạn thấy một ngày là không đủ để thuận tiện ổn định phát hành, phải không? với chiến lược phân nhánh mới, bạn chỉ có thể rẽ nhánh 2 ngày trước khi phát hành thay vì một, không vấn đề gì. Nếu bạn thấy rằng thậm chí hai ngày là không đủ, hãy thử chuyển 3 ngày trước đó, v.v. Điều đó là, bạn có thể cách ly nhánh phát hành sớm như bạn muốn vì điều này sẽ không chặn việc hợp nhất mã mới vào nhánh tích hợp nữa. Lưu ý trong mô hình này, không cần phải đóng băng chi nhánh tích hợp - các nhà phát triển của bạn có thể liên tục sử dụng nó, vào Thứ Hai, Thứ Ba, Thứ Sáu, bất cứ điều gì.
Cái giá bạn phải trả cho hạnh phúc này là sự phức tạp của các hotfix. Chúng phải được hợp nhất thành hai nhánh thay vì một (phát hành + tích hợp). Đây là những gì bạn nên tập trung vào khi thử nghiệm mô hình mới. Theo dõi tất cả những gì có liên quan - nỗ lực thêm mà bạn dành cho việc sáp nhập vào chi nhánh thứ hai, những nỗ lực liên quan đến rủi ro mà người ta có thể quên sáp nhập vào chi nhánh thứ hai - mọi thứ liên quan.
Khi kết thúc thử nghiệm, chỉ cần tổng hợp những gì bạn đã theo dõi và tìm hiểu xem số tiền của nỗ lực bổ sung này có được chấp nhận hay không. Nếu nó được chấp nhận, bạn đã hoàn thành. Nếu không, hãy quay lại mô hình hiện tại của bạn, phân tích những gì đã sai và bắt đầu suy nghĩ về cách khác mà bạn có thể cải thiện.
cập nhật2
<sao chép từ ý kiến>
Mục đích của tôi là để có được các câu chuyện được kiểm tra và có thể phân phối (phía sau hoặc phía trước bức tường cấu hình) trong một lần lặp, điều này chỉ có thể đạt được nếu người kiểm tra đang thực hiện công việc kiểm tra được thực hiện trong vòng lặp (và không ổn định mã từ lần lặp trước).
</ sao chép từ ý kiến>
Tôi hiểu rồi. Vâng, tôi không có kinh nghiệm trực tiếp theo cách đó nhưng đã thấy thử nghiệm loại lặp đi lặp lại được thực hiện thành công trong một dự án liên quan đến chúng tôi. Vì dự án của chúng tôi đã đi theo cách ngược lại, tôi cũng có một sự so sánh trực diện đối với các phương pháp ngược lại này .
Từ quan điểm của tôi, out-of-lặp phương pháp thử nghiệm nhìn vượt trội trong cuộc đua đó. Vâng, dự án của họ đã hoạt động tốt và những người thử nghiệm của họ đã phát hiện ra các lỗi nhanh hơn so với chúng tôi nhưng bằng cách nào đó, điều này không giúp được gì. Dự án của chúng tôi cũng đã ổn, và bằng cách nào đó, chúng tôi có thể đủ khả năng lặp lại ngắn hơn so với chúng và chúng tôi có các bản phát hành bị trượt ít hơn (ít hơn nhiều) so với chúng, và có ít căng thẳng hơn giữa dev và testers ở bên chúng tôi.
BTW mặc dù phát hiện nhanh hơn ở phía họ, chúng tôi đã xoay sở để có cùng tuổi thọ lỗi trung bình (tuổi thọ là thời gian giữa giới thiệu và sửa lỗi , không phải giữa giới thiệu và phát hiện). Có lẽ chúng tôi thậm chí đã có một lợi thế nhỏ ở đây vì với các lần lặp ngắn hơn và các bản phát hành ít bị trượt hơn, chúng tôi có thể tuyên bố rằng trung bình các bản sửa lỗi của chúng tôi tiếp cận người dùng nhanh hơn so với của họ.
Tóm tắt, tôi vẫn tin rằng sự cô lập của dòng mã phát hành có cơ hội tốt hơn để cải thiện năng suất nhóm của bạn.
về một suy nghĩ xa hơn ...
- sự cô lập của dòng mã phát hành có cơ hội tốt hơn - khi đọc lại tôi cảm thấy điều này có thể tạo ấn tượng rằng tôi không khuyến khích bạn thử kiểm tra lặp lại . Tôi muốn làm cho nó hoàn toàn rõ ràng rằng tôi không.
Trong trường hợp của bạn, phương pháp thử nghiệm lặp lại có vẻ an toàn để thử (er ... test ) bởi vì bạn dường như hiểu rõ về cách đạt được nó ( đường ống thử nghiệm trơn tru ) và những trở ngại chính là gì. Và sau tất cả, bạn luôn có một tùy chọn để quay lại phương pháp thay thế nếu bạn thấy quá khó để có được đường ống đó đúng.
BTW liên quan đến các trở ngại, những vấn đề bổ sung đáng theo dõi trong trường hợp đó sẽ là các vấn đề như không thể tái tạo lỗi ở phía dev và trễ để tìm / trễ để xác minh sửa chữa ở phía người kiểm tra. Chúng cũng có thể bị kẹt đường ống của bạn , giống như nó xảy ra với các hotfix.