Làm thế nào có thể xác minh thành công các thay đổi gây ra hồi quy đáng lẽ phải bị bắt?

Trong bối cảnh CI, một trong những biện pháp thường được sử dụng để tăng mức chất lượng của nhánh tích hợp là một tập hợp bắt buộc của xác minh chất lượng trước khi cam kết (thường bao gồm xây dựng một số tạo tác, thực hiện kiểm tra đơn vị và thậm chí một số kiểm tra tính năng / tích hợp).

Tuy nhiên, một số hồi quy (phá vỡ bản dựng, các lỗi thử nghiệm khác nhau) được phát hiện bởi các xác minh hệ thống CI trong chính xác các khu vực được cho là được bao phủ bởi các xác minh trước khi cam kết bắt buộc này.

Trong quá trình phân tích các hồi quy này, một lập luận thường được nghe là nhà phát triển đã cam kết thay đổi được xác định là nguyên nhân gốc của hồi quy đã vượt qua tất cả các xác minh như vậy. Và thường thì yêu cầu được hỗ trợ bởi bằng chứng cứng cho thấy:

• sau khi đạt được phiên bản cuối cùng của sự thay đổi, nó đã được chuyển đến một không gian làm việc mới dựa trên đỉnh của nhánh
• các tạo phẩm cần thiết được xây dựng từ đầu (vì vậy bản dựng hoàn toàn tốt, không có vấn đề liên quan đến bộ đệm, v.v.)
• tất cả các thử nghiệm bắt buộc đã được thông qua, bao gồm cả những thử nghiệm bao gồm khu vực được đề cập và đã phát hiện ra hồi quy
• không có dương tính giả không liên tục ảnh hưởng đến các xác minh tương ứng
• không có sự hợp nhất tập tin nào được phát hiện khi cam kết thay đổi chi nhánh
• không có tệp nào được sửa đổi bị chạm bởi bất kỳ thay đổi nào khác được cam kết trong chi nhánh kể từ khi không gian làm việc mới được kéo

Có thực sự thay đổi phần mềm có thể gây ra hồi quy như vậy mặc dù tuân thủ chính xác tất cả các quy trình và thực tiễn được quy định không? Làm sao?

Có một khả năng tôi có thể nghĩ đến, nếu khi nhà phát triển làm việc trên máy trạm của họ, đôi khi hình ảnh được nướng cho hộp ảo để chạy trên máy trạm của họ, nơi cơ sở hạ tầng của bạn không sử dụng cùng một hình ảnh.

Nhà phát triển sẽ cần, trong khi phát triển một tính năng, cần thêm một tham số JVM hoặc bất kỳ thay đổi nào đối với phần mềm trung gian trong công việc của nó và quên nó đi.

Trước khi cam kết, tất cả các thử nghiệm đơn vị / tích hợp chạy trên máy trạm của nó hoạt động rất tốt, vì hình ảnh được chia sẻ, nó hoạt động trên mọi hệ thống develloper.

Nhưng khi đi qua CI, nó thất bại vì thay đổi đối với kho trung gian đã không được thực hiện, vì nhà phát triển quên yêu cầu hoặc chỉ vì nhóm chịu trách nhiệm cập nhật hình ảnh / hệ thống cung cấp cơ sở không có thời gian hoặc đã quên cập nhật hệ thống.

Đó là một điều tốt khi nó phá vỡ CI, bởi vì nó nói sớm trước khi đi vào sản xuất rằng hệ thống sẽ không hoạt động như mong đợi, nhưng đôi khi nó trở thành địa ngục để tìm ra tham số bị thiếu.

Điểm cuối cùng này ủng hộ để tránh từ chối các cam kết và chỉ phá vỡ CI trên một nhánh tính năng, do đó nó sẽ không chặn bất kỳ ai khác và để nhà phát triển khắc phục sự cố sớm, khi cần thay đổi và ngăn sự thay đổi này bị quên dòng chảy.

FWIW, chúng tôi đã làm chính xác điều này ở đây, các nhà phát triển có toàn quyền truy cập vào các máy phát triển và phát hành trong Q / A đã thất bại vì thay đổi tham số đã bị quên, chúng tôi đã chuyển sang đầu bếp để xử lý cấu hình của phần mềm trung gian (bây giờ là tomcat) thay đổi cơ sở hạ tầng phải được mã hóa ở đâu đó và sẽ được sao chép trong mọi môi trường.

Chắc chắn đó là. Sản xuất luôn khác nhau. Tiền thật. Tải thực. Người dùng thực sự. Nỗi đau thực sự. Đây là lý do tại sao nó rất quan trọng để đặt bất kỳ thay đổi đáng kể đằng sau một cờ tính năng. Việc triển khai của bạn không nên thay đổi bất cứ điều gì. Bật một tính năng là điều duy nhất sẽ tạo ra những thay đổi đáng kể cho trang web của bạn.

Sự cố luôn luôn có thể về mặt lý thuyết bởi vì xác minh trước khi cam kết được thực hiện bởi nhà phát triển được thực hiện một cách cô lập và do đó không thể tính đến các thay đổi trên chuyến bay khác được xác minh song song. Những thay đổi như vậy có thể gây trở ngại cho nhau và gây ra hồi quy mà không thực sự có thể thu thập được ở cấp độ SCM.

Một ví dụ đơn giản về những thay đổi gây nhiễu như vậy:

Giả sử mã trong phiên bản mới nhất của nhánh dự án bao gồm một chức năng nhất định, được xác định trong một tệp và được gọi trong một vài tệp khác. Hai nhà phát triển làm việc song song trong dự án đó đang chuẩn bị thực hiện một số thay đổi cho mã.

Nhà phát triển Một bản làm lại có chức năng loại bỏ hoặc thêm một đối số chức năng bắt buộc và, tất nhiên, cập nhật tất cả các yêu cầu của hàm trong tất cả các tệp được liên kết để phù hợp với định nghĩa được cập nhật.

Nhà phát triển B quyết định thêm một lời gọi của hàm đã nói trong một tệp không chứa bất kỳ lời gọi nào như vậy trước đó và do đó không bị thay đổi bởi các thay đổi của nhà phát triển A. Tất nhiên nhà phát triển B đang điền vào danh sách đối số để khớp với định nghĩa của hàm hiển thị trong nhãn mới nhất. Đó là định nghĩa cũ, vì những thay đổi của nhà phát triển A chưa được cam kết.

Cả hai nhà phát triển thực hiện chính xác các xác minh trước khi cam kết với kết quả vượt qua và tiến hành cam kết thay đổi mã của họ. Vì hai thay đổi không chạm vào cùng một tệp nên không có sự hợp nhất cuối cùng, điều này thường là dấu hiệu của các vấn đề tiềm ẩn, đảm bảo xem xét kỹ hơn và có thể thực hiện lại xác minh trước khi xác nhận. Không có bất cứ điều gì có thể đưa ra ngay cả một gợi ý tinh tế rằng một cái gì đó có thể đi sai.

Tuy nhiên, kết quả cuối cùng là thảm khốc - bản dựng bị hỏng do lệnh gọi hàm được thêm bởi nhà phát triển B không khớp với định nghĩa hàm được cập nhật bởi nhà phát triển A.

Khi bạn tìm thấy loại sự cố này, bạn nên viết một số thử nghiệm chấp nhận chạy cực kỳ nhanh mới có thể khắc phục các sự cố này và thêm chúng vào các thử nghiệm xác minh bản dựng chạy trước các thử nghiệm tích hợp của bạn. Bạn nên liên tục dịch chuyển sang trái và cố gắng rút ngắn vòng phản hồi để các nhà phát triển cam kết thay đổi. Nếu bạn không thể tìm ra cách để làm điều này, có lẽ kiến ​​trúc của bạn không nhanh nhẹn như nó cần phải có.

@Dan Cornilescu - kịch bản của bạn hợp lệ đối với các kiến ​​trúc được liên kết chặt chẽ, đó là lý do tại sao các kiến ​​trúc được ghép lỏng lẻo (microservice của các API RESTful được phiên bản) đã nổi lên như là cách thực hành tốt nhất hiện nay trong các tổ chức hiệu suất cao. Các ma trận của các tổ chức dịch vụ có những phức tạp khác để khắc phục mặc dù.

Đôi khi bạn cần cấu trúc lại toàn bộ kiến ​​trúc của mình để khắc phục các vấn đề như vậy. Tôi tin rằng cả Google và eBay đã nghiên cứu hoàn toàn nền tảng của họ 5 lần (trong khoảng thời gian 10 năm) do những hạn chế về kiến ​​trúc trước đây của họ áp đặt lên chúng.