Làm thế nào để tránh sự mất ổn định do tích hợp liên tục trong môi trường thử nghiệm?

Giả sử bạn đang sử dụng các quy trình tích hợp liên tục thường xuyên cập nhật một số môi trường đích, để mỗi khi có một số thay đổi "bạn" có thể kiểm tra các thay đổi của bạn ngay lập tức. Đó là một phần trong mục tiêu của CI, phải không?

Nhưng, cũng giả sử rằng bạn có những người khác tham gia vào chu kỳ thử nghiệm của mình, ví dụ: người quản lý hoặc khách hàng. Có ý nghĩa để khiến người khác tham gia vào việc cố gắng xem xét (phá vỡ?) Những thay đổi sắp tới của bạn, không?

Nhưng nếu bạn liên tục đưa ra những thay đổi trong môi trường mà những người khác đang nghiêm túc thử nghiệm chúng, thì nhiều vấn đề có thể phát sinh, chẳng hạn như:

• they có thể lãng phí thời gian của họ trong việc báo cáo các vấn đề, vào thời điểm họ lưu báo cáo (chuyên sâu), họ thậm chí không thể tự tái tạo vấn đề nữa (ví dụ: vì vô tình bạn cũng gặp phải vấn đề tương tự và đã khắc phục nó trong môi trường của họ).
• you có thể không thể tái tạo các vấn đề mà họ đã báo cáo, vì các môi trường mà họ gặp phải một số vấn đề, không còn giống nhau (bạn (!!!) có thể đã che phủ môi trường của họ).

Vì vậy, bạn có thể làm gì (làm thế nào để cấu hình mọi thứ?) Để tránh những tình huống (bực bội) như vậy?

Tôi sẽ đưa ra kinh nghiệm của mình về vấn đề này, chủ yếu là vì nó cho thấy lý do tại sao một số câu trả lời không phải lúc nào cũng được áp dụng.

Một số bối cảnh để bắt đầu:

• Chúng tôi có 7 môi trường để lưu trữ khoảng 80 ứng dụng, hầu hết chúng dựa vào nhau thông qua các dịch vụ web hoặc các bảng được chia sẻ trên db2-iSeries.
• Dù tốt hay xấu, iSeries là hệ thống tham chiếu DB của chúng tôi.
• Điểm cuối cùng này làm mất hiệu lực mọi ý tưởng mang ứng dụng với các phụ thuộc của nó trong một môi trường bị cô lập vì việc đưa ra một AS400 cho mỗi cái sẽ tốn quá nhiều tiền và chúng tôi sẽ không có phần cứng để chạy nó.

Những gì chúng tôi đang làm không phải là Giao hàng liên tục tự động hoàn chỉnh, chúng tôi có lịch phát hành để đưa ra rất nhiều ứng dụng mạch lạc cho các hoạt động chung. Ngoài ra, mỗi nhóm thử nghiệm có thể kích hoạt một bản phát hành trong một trong những môi trường Q / A cho ứng dụng mà họ đang thử nghiệm và có thể khóa trên một số phiên bản ứng dụng để tránh yêu cầu nhóm khác phá vỡ các thử nghiệm của họ.

Sự phụ thuộc của các ứng dụng được kiểm tra trước khi phát hành, vì vậy hệ thống sẽ không phát hành thứ gì nếu các ứng dụng khác không thể được cập nhật hoặc không phù hợp với sự phụ thuộc của nó. Ý tưởng chính là cho phép cập nhật khi nó không ảnh hưởng đến ai đó, nếu không có kế hoạch kiểm tra, nó sẽ chảy từ môi trường trước đó (và chúng tôi đang nhắm đến việc loại bỏ các bản phát hành theo lịch trình trong 5 môi trường đầu tiên vào giữa kỳ bây giờ chúng tôi có xác nhận hệ thống phương pháp 'theo yêu cầu' này).

Phiên bản ngắn là có hệ thống 'semaphore' xung quanh các ứng dụng trong môi trường, một nhóm sẽ có thể khóa ứng dụng mục tiêu của mình bằng các phụ thuộc (và phụ thuộc bắc cầu) trong thời gian thử nghiệm thủ công.
Việc triển khai semaphore này phụ thuộc nhiều vào hệ thống tự động hóa của bạn, vì vậy tôi sẽ không mở rộng về điều đó.

Tất nhiên, cách dễ dàng là, như những người khác đã đề cập, để tạo ra một môi trường mới cho một ứng dụng với tất cả các phụ thuộc của nó để tránh semaphore được mô tả ở trên.

Âm thanh như bạn đang nói về một môi trường thử nghiệm được sử dụng lại liên tục mà không được khởi tạo lại một cách đáng tin cậy cho mỗi lần thực hiện thử nghiệm. Điều này làm cho thử nghiệm như vậy là không đáng tin cậy. Tương tự, từ quan điểm độ tin cậy, với thử nghiệm thủ công, nếu bạn muốn.

IMHO bạn không nên sử dụng thử nghiệm như vậy bên trong các mục đích chứng nhận CI / CD của mình vì điều đó sẽ vô hiệu hóa quá trình kiểm tra chất lượng của bạn (ít nhất là trong khu vực đó). Nói rằng phần mềm vượt qua thử nghiệm X mà không thực hiện thử nghiệm X cho mọi phiên bản phần mềm được phân phối hoặc không có sự chắc chắn rằng passkết quả thu được không phải là ngẫu nhiên (do dương tính giả) sẽ làm xói mòn mức độ tin cậy của thử nghiệm của bạn. Âm tính giả không gây tổn hại đến uy tín, nhưng chúng cũng không được mong đợi vì "tiếng ồn" không cần thiết mà chúng tạo ra.

Thật tốt khi thực hiện kiểm tra như vậy bên ngoài quy trình kiểm định chất lượng CI / CD của bạn. Nhưng bạn đang xử lý một kết quả thất bại trong thử nghiệm như vậy giống như lỗi do khách hàng tìm thấy: bạn cần tái tạo một cách đáng tin cậy vấn đề để có thể phát triển bản sửa lỗi và xác nhận rằng bản sửa lỗi đang hoạt động. Và bạn không thể thực sự làm điều đó nếu thử nghiệm không đáng tin cậy.

Nếu bạn có kế hoạch giải quyết vấn đề thì lý tưởng nhất là trước tiên bạn sẽ phát triển một trường hợp kiểm tra tự động, đáng tin cậy để tái tạo vấn đề. Mà bạn sử dụng để phát triển bản sửa lỗi và xác nhận tính hiệu quả của nó (kết quả kiểm tra nên chuyển từ FAIL sang PASS). Bạn cũng có thể (nên?) Đặt bản thử nghiệm này trong quy trình kiểm định chất lượng CI / CD của mình để ngăn chặn sự tái xuất hiện trong tương lai, nếu muốn - để tăng mức chất lượng phát hành phần mềm tổng thể của bạn.

Cách tiếp cận thông thường là tạo ra các môi trường khác nhau:

DEV - đây là nơi mà nhóm phát triển làm rối tung mọi thứ. Dưới đây là tạo tất cả các điều chỉnh thay đổi, triển khai phiên bản mới và như vậy. Đây là nơi CI được tích hợp đầy đủ.

PREPROD / QA - đây là nơi "chơi" QA / nhóm kiểm tra / xác nhận làm bài kiểm tra. Môi trường này thường đóng băng trong các thử nghiệm. Tích hợp CI với môi trường này chỉ để cung cấp phiên bản mới của sản phẩm, cấu hình, v.v.

SẢN XUẤT - có cần phải giải thích :)?

Nếu bạn đang thực hiện CI / CD, điều đó có nghĩa là có một số thử nghiệm tự động xảy ra (CI) trước khi triển khai (CD). Nếu bạn đang tìm thấy nhiều vấn đề trong môi trường thử nghiệm của mình, điều đó có nghĩa là chúng không bị bắt bởi các thử nghiệm đang được chạy trước khi triển khai; điều này cho thấy không đủ kiểm tra tự động. Nếu các nhà phát triển đang gặp vấn đề trong đó các lỗi phát sinh trong môi trường thử nghiệm, họ cần cải thiện các bộ kiểm thử tự động để ngăn chặn điều này. Điều này cũng sẽ cải thiện chất lượng và độ tin cậy tổng thể, tất cả các cách thông qua sản xuất.

Để thêm vào câu trả lời của Romeo Ninov, bên trong một môi trường bạn cần thử và tách các ứng dụng càng nhiều càng tốt. Đây là một phần lý do tại sao docker đã rất thành công cho dev / test. Nó cho phép bạn gần như giả vờ rằng bạn hoàn toàn không chia sẻ một môi trường.

Tùy chọn khác là có các máy chủ được xác định rất rõ ràng trên đó các ứng dụng chạy tách biệt với phần còn lại của cơ sở hạ tầng tạo nên môi trường của bạn. I E. Tất cả các máy móc quản lý môi trường hoặc hỗ trợ hoạt động trên các máy chủ riêng biệt, tồn tại lâu dài. Sau đó, bạn nối vào các máy chủ có thời gian tồn tại ngắn dựa trên một hình ảnh đã biết để kiểm tra một ứng dụng và, nếu có bất kỳ thay đổi nào được thực hiện đối với hình ảnh cơ sở, bạn cần áp dụng những thay đổi đó ở mọi nơi cho mọi thành phần mới. Có nghĩa là thử nghiệm những thay đổi chống lại mọi thứ.

Nếu một nhóm appdev yêu cầu thay đổi phá vỡ ứng dụng của người khác, thì thật may mắn, họ cần phải tạo ra một bộ giảm nhẹ trong mã của họ và tách biệt các yêu cầu cụ thể của họ khỏi môi trường cung cấp.