Làm thế nào để giữ thân cây ổn định khi các xét nghiệm mất nhiều thời gian?


9

Chúng tôi có ba bộ thử nghiệm:

  • Một bộ "nhỏ", chỉ mất vài giờ để chạy
  • Một bộ "vừa" mất nhiều giờ, thường được chạy mỗi đêm (hàng đêm)
  • Một bộ "lớn" mất một tuần + để chạy

Chúng tôi cũng có một loạt các bộ thử nghiệm ngắn hơn, nhưng tôi không tập trung vào chúng ở đây.

Phương pháp hiện tại là chạy bộ nhỏ trước mỗi lần xác nhận vào thân cây. Sau đó, bộ công cụ trung bình chạy mỗi đêm, và nếu vào buổi sáng thì nó bị lỗi, chúng tôi cố gắng cách ly những cam kết của ngày hôm qua là đổ lỗi, khôi phục lại cam kết và thử lại các bài kiểm tra. Một quy trình tương tự, chỉ với tần suất hàng tuần thay vì tần suất hàng đêm, được thực hiện cho bộ lớn.

Thật không may, bộ trung bình không thất bại khá thường xuyên. Điều đó có nghĩa là thân cây thường không ổn định, điều này cực kỳ khó chịu khi bạn muốn thực hiện sửa đổi và kiểm tra chúng. Thật khó chịu vì khi tôi kiểm tra từ thân cây, tôi không thể biết chắc chắn nó ổn định và nếu thử nghiệm thất bại tôi không thể biết chắc chắn đó có phải là lỗi của tôi hay không.

Câu hỏi của tôi là, có một số phương pháp được biết đến để xử lý các loại tình huống này theo cách sẽ khiến thân cây luôn ở trạng thái tốt nhất? ví dụ: "cam kết vào một nhánh preommit đặc biệt, sau đó sẽ định kỳ cập nhật thân cây mỗi khi đêm trôi qua".

Và có vấn đề gì không nếu nó là một hệ thống kiểm soát nguồn tập trung như SVN hoặc một hệ thống phân tán như git?

Nhân tiện, tôi là một nhà phát triển cơ sở với khả năng thay đổi mọi thứ hạn chế, tôi chỉ cố gắng hiểu liệu có cách nào để xử lý nỗi đau này mà tôi đang trải qua.


6
Tôi không biết bạn đang làm việc trên phần mềm nào, nhưng một bộ thử nghiệm nhỏ phải mất hàng giờ để chạy là một số WTF. Nếu họ chạy nhanh hơn thì điều này sẽ dễ dàng hơn, không có cách nào để hợp lý hóa các bài kiểm tra của bạn?
Benjamin Bannier

2
Điều gì "cực kỳ khó chịu" về thân cây không ổn định? Không biết nếu bạn biết, nhưng một trong những chiến lược phân nhánh phổ biến nhất thậm chí còn được gọi là thân cây không ổn định
gnat

1
Có nhiều cách để tối ưu hóa một bộ kiểm tra (như đối với bất kỳ phần mềm nào khác). Tôi không biết tại sao bạn lại mất nhiều thời gian như vậy, nhưng bạn có thể sử dụng lại một số môi trường thử nghiệm hoặc chỉ sử dụng các thuật toán / cấu trúc dữ liệu tốt hơn khi chạy (lược tả giúp). Cũng có thể là không ai dành thời gian để xác định các mẫu đại diện và bạn chỉ cần kiểm tra mọi đầu vào / đầu ra có thể dựa trên một số tham chiếu. Có thể hệ thống xây dựng của bạn cho phép bạn mã hóa các phụ thuộc kiểm tra mã để bạn không cần phải chạy toàn bộ. Và tôi biết đây không phải là câu hỏi của bạn, đó là lý do tại sao tôi đưa ra nhận xét chứ không phải câu trả lời.
Benjamin Bannier

1
... hmm, tùy chọn tốt hơn của bạn có khả năng cải thiện các bài kiểm tra và ghi nhật ký ứng dụng để dễ dàng tìm ra lý do thất bại. Bằng cách đó, người ta sẽ cần tìm và khắc phục nguyên nhân thất bại thay vì lãng phí nỗ lực vào "điều tra thám tử" để tìm kiếm ai, khi nào và tại sao thay đổi dòng mã cụ thể ...
gnat

1
@honk Một số bài kiểm tra chỉ mất nhiều thời gian để chạy. Tôi làm việc cho một công ty sản xuất thiết bị thu thập dữ liệu và quá trình chạy thử "một phần" của chúng tôi mất khoảng một giờ. Các xét nghiệm cần thực hiện các loại phép đo khác nhau và điều đó chỉ mất thời gian.
Velociraptors

Câu trả lời:


1

Cách duy nhất để khắc phục nguyên nhân gốc rễ của sự không ổn định là tách mã để các thay đổi bị cô lập hơn, như các câu trả lời khác đã đề xuất.

Tuy nhiên, là một nhà phát triển cá nhân, nếu bạn muốn xây dựng ổn định hơn cho cá nhân bạn để làm việc, điều đó tương đối dễ giải quyết. Thay vì làm việc hết tiền boa, bạn chỉ kéo bản dựng cuối cùng đã vượt qua bộ kiểm tra qua đêm vào cây làm việc của bạn. Nếu bạn có thể tạo các nhánh tính năng cho mỗi thay đổi, thì hãy tách nhánh của bản dựng ổn định cuối cùng.

Vâng, cây của bạn sẽ chậm một vài ngày, nhưng hầu hết thời gian không thành vấn đề. Làm công việc của bạn chống lại bản dựng ổn định, để bạn biết những thay đổi của bạn là những thay đổi đã phá vỡ mọi thử nghiệm, sau đó trước khi bạn đăng ký, cập nhật lên bản mới nhất và thực hiện tích hợp bình thường. Sau đó, sau khi bạn đăng ký, hãy sao lưu bản dựng ổn định cuối cùng một lần nữa.

Bạn vẫn phải thực hiện công việc tích hợp lộn xộn, nhưng điều tôi thích ở phương pháp này là nó cách ly công việc tích hợp để thuận tiện hơn cho tôi và cho tôi cơ sở mã ổn định để phát triển khi không thuận tiện. Tôi có một ý tưởng tốt hơn nhiều khi những thay đổi của tôi có khả năng phá vỡ công trình so với người khác.


1
-1 làm việc từ các chi nhánh là lựa chọn khả thi, nhưng khuyến nghị nó mà không có gợi ý để kiểm tra có thể gây hại nhiều hơn là tốt. Chỉ thử nghiệm có thể cho thấy liệu nó có khả thi cho dự án cụ thể hay không. Ví dụ, trong một dự án tôi đã thực hiện khoảng 2 năm trước, một thử nghiệm như vậy cho thấy làm việc từ các chi nhánh đã nỗ lực gấp 7 lần so với thân cây không ổn định
gnat

Cảm ơn Karl! Mặc dù đây không phải là điều tôi mong muốn học hỏi, nhưng đây là một cách tiếp cận rất thực tế có thể giúp tôi giải quyết vấn đề trong tay. Và tôi đồng ý rằng làm việc một vài ngày sau thân cây sẽ hiếm khi gây ra vấn đề tích hợp.
Oak

12

Tôi biết bạn đang cố gắng tránh điều này, nhưng cái nhìn sâu sắc thực sự ở đây là nhận ra rằng có điều gì đó không ổn với cơ sở mã của bạn: bạn cần chạy một bộ thử nghiệm đầy đủ mất một tuần chỉ để đảm bảo mã của bạn ổn định!

Cách thuận lợi nhất để khắc phục vấn đề này là bắt đầu tách cơ sở mã của bạn và kiểm tra thành các đơn vị con (độc lập).
Có những lợi thế rất lớn cho việc này:

  • Các thử nghiệm cho từng đơn vị đó sẽ chạy nhanh hơn (đơn giản là ít hơn trong số chúng) và chúng sẽ không bị hỏng nếu xảy ra sự cố ở một trong các đơn vị độc lập hoặc hạ nguồn.
  • Một bài kiểm tra thất bại sẽ được xác định chính xác đến một đơn vị cụ thể, điều này sẽ giúp việc tìm ra nguồn gốc của vấn đề dễ dàng hơn nhiều.
  • Bạn có thể tách các vị trí VCS của các đơn vị khác nhau để nhánh "ổn định" của bạn có thể là một hỗn hợp chọn của bản dựng được thử nghiệm thành công mới nhất của mỗi đơn vị, để một hoặc hai đơn vị bị hỏng không làm mất ổn định phiên bản "ổn định" của bạn .

Về mặt quản lý flipside của cấu trúc VCS của bạn sẽ trở nên phức tạp hơn, nhưng vào một tuần đầy đủ cho bài kiểm tra đầy đủ của bạn, tôi nghĩ bạn có thể chịu đau!

Tôi vẫn khuyên bạn nên sử dụng chiến lược chi nhánh "ổn định" và "phát triển" dưới hình thức này hay hình thức khác, nhưng có nhiều cách để giải quyết vấn đề đó và bạn có thể chọn chiến lược phù hợp nhất với tổ chức của mình (kho lưu trữ meta với các phiên bản cố định chỉ vào kho riêng cho từng đơn vị, nhánh ổn định và nhánh dev, nhánh tính năng ....)


1
Tôi chưa bao giờ nói những thử nghiệm lớn là một thử nghiệm nguyên tử, đó là một thử nghiệm bộ . Khi một nhà phát triển cá nhân thực hiện sửa đổi thành phần X, anh ta sẽ chạy các thử nghiệm có liên quan đến X - bất kể họ có nguồn gốc từ bộ thử nghiệm nào. Đây là ngoài thử nghiệm hàng tuần, được thực hiện để đảm bảo rằng sự thay đổi ở một nơi không bất ngờ ảnh hưởng đến một nơi khác. Nhưng bạn có một điểm thú vị là ít nhất tách biệt mọi thứ theo cách này sẽ giúp tăng tốc độ kiểm tra cho các mô-đun cụ thể, trong khi vẫn giữ rủi ro ở mức gần như nhau.
Oak

2
@oak - Chà, theo cách mà bộ nguyên tử IS nếu chạy tất cả thì đó là cách duy nhất bạn thực sự tin rằng mã ổn định, nhưng bạn đã làm tốt, vì vậy tôi đã chỉnh sửa câu trả lời của mình.
Joris Timmermans

4
Chúng tôi có các thử nghiệm lớn cho trình biên dịch của chúng tôi, một số trong đó phải mất vài ngày để chạy và tôi không nghĩ rằng điều đó không phổ biến đối với phần mềm phức tạp như trình biên dịch C ++. Không phải là bộ định nghĩa được coi là "ổn định", mà là có hàng triệu trường hợp tạo mã khác nhau mà không thể kiểm tra chúng mỗi ngày.
JesperE

1
@JesperE - điều đó có thể hiểu được, nếu bộ thử nghiệm khổng lồ không định nghĩa "ổn định" mà là một thử nghiệm độ tỉnh táo khổng lồ. Tôi không mong đợi bộ đầy đủ (hoặc thậm chí bộ trung bình) sẽ thất bại rất thường xuyên.
Joris Timmermans

1

Đối với SVN, tôi không biết về một thứ như "cam kết trước". Tôi nghĩ rằng nó có khả năng tạo ra các cam kết và rollback khi thử nghiệm thất bại. Như doc-brown nói, cách duy nhất là phải cam kết trên một nhánh tạm thời và hợp nhất nó với thân cây sau này.

Sử dụng một phân phối như git hoặc đồng bóng, tôi nghĩ rằng nó sẽ có thể. Sử dụng kho lưu trữ "thử nghiệm" và kho lưu trữ "ổn định". Bạn đẩy đại diện kiểm tra, kiểm tra hàng đêm và nếu mọi thứ chạy tốt, bạn đẩy từ kiểm tra sang ổn định. Nếu không, bạn rollback các đại diện thử nghiệm. Tôi hơi không chắc lịch sử phiên bản sẽ như thế nào khi bạn chuyển từ thử nghiệm sang ổn định, nhưng tôi nghĩ có thể loại trừ những thứ bị lật ngược bị hỏng khi làm như vậy. Một chút thử nghiệm đầu tiên sẽ là an toàn nhất.

Một cách khác cũng sẽ là kiểm tra thân cây địa phương mỗi đêm. Sau đó, những người có bài kiểm tra được thông qua được phép đẩy nó đến máy chủ trung tâm vào buổi sáng.


1

IMHO điều này không liên quan gì đến VCS bạn đang sử dụng. Sử dụng một nhánh "đang thử nghiệm" có thể là giải pháp, có thể được thực hiện với VCS tập trung hoặc phân tán. Nhưng thành thật mà nói, tôi nghĩ điều tốt nhất trong tình huống của bạn là cố gắng tối ưu hóa bộ kiểm tra trung bình (dường như nó chứa các bài kiểm tra quan trọng nhất) để nó chạy nhanh hơn nhiều, vì vậy bạn có thể sử dụng nó để kiểm tra trước kiểm tra, giống như bạn làm điều đó ngay bây giờ với "bộ nhỏ" của bạn.


Tôi chủ yếu hỏi về phương pháp luận ở đây - tức là, có một cách phổ biến để đối phó với tình huống như vậy. Giả sử, ít nhất là vì lợi ích của cuộc thảo luận này, rằng các bài kiểm tra không thể được tối ưu hóa ngoài những gì chúng đã có.
Sồi

@Oak: ai đó ở đây (bạn?) Đã bỏ phiếu cho câu trả lời của tôi - nhưng đôi khi những điều bạn không muốn nghe là những điều duy nhất sẽ giúp ích. Như bạn thấy trong cuộc thảo luận bên dưới câu hỏi của bạn, những người khác cũng đề xuất như vậy, vì vậy đề xuất của tôi dường như không tệ lắm.
Doc Brown

+1, đây là câu trả lời đúng. Câu hỏi thực sự của OP là "Giúp đỡ, tôi đang chìm đắm trong crap, tôi có thể sử dụng phương pháp nào để tự giúp mình?" và câu trả lời là phương pháp thực sự không phải là điều bạn nên lo lắng.
MrFox

1

Các bài kiểm tra trung bình thất bại: Có đúng là hầu hết các bài kiểm tra tương tự đều thất bại?

Nếu có một thất bại thì luôn có những bài kiểm tra liên quan tương tự mà thất bại?

Nếu đúng: Có thể bạn có thể chọn lọc một số bài kiểm tra trung bình thường thất bại (một bài kiểm tra cho mỗi lớp lỗi) và thực hiện chúng trong tập nhỏ.

Có phải hầu hết các bài kiểm tra tích hợp kiểm tra sử dụng một cơ sở dữ liệu thực sự? Nếu vậy, có thể thay thế chúng bằng một cơ sở dữ liệu bị nhạo báng không?


1

Bạn cần làm cho bài kiểm tra của mình chạy nhanh hơn, không có cách nào khác để bình phương vòng tròn này.

Xem xét vấn đề: bạn muốn chắc chắn rằng khi bạn kiểm tra, bạn có mã làm việc. Chắc chắn, bạn có thể trì hoãn các cam kết và thực hiện phân nhánh cho đến trước khi phát hành, nhưng điều đó sẽ chỉ trì hoãn sự khởi đầu của vấn đề cho đến khi tích hợp. Như trong, bạn sẽ phải chạy bộ kéo dài một tuần sau mỗi lần hợp nhất? Phương pháp không phải là giải pháp, giải pháp hoàn toàn là kỹ thuật.

Đây là những gì tôi đề nghị:

1) Thực hiện các bài kiểm tra càng ít càng tốt và tối đa hóa việc tái sử dụng môi trường.

2) Nhận một trang trại thử nghiệm để chạy chúng. Nếu thay vì 8 mô-đun lớn mà bạn kết thúc với 50, bạn có thể quay một loạt các phiên bản tại chỗ Amazon EC2 và chạy song song toàn bộ bộ. Tôi chắc chắn rằng điều này sẽ tốn một số tiền, nhưng nó sẽ tiết kiệm được lượng lớn thời gian của nhà phát triển.


0

Điều quan trọng mà bạn đang thực hiện trong câu hỏi của bạn là tất cả các cam kết phải vượt qua các bài kiểm tra. Mặc dù đây là một quy tắc tốt để tuân theo và nó có vẻ có ý nghĩa, đôi khi nó không thực tế. Trường hợp của bạn là một ví dụ (mặc dù MadKeithV không đưa ra quan điểm nào) và tôi có thể tưởng tượng việc giữ một nhánh VCS sao cho sự nguyên sơ có thể khó khăn nếu không có sự hợp tác đầy đủ giữa các nhà phát triển.

Trong thực tế những gì bạn muốn là bằng cách nào đó biết những gì cam kết vượt qua hoặc thất bại. Một "chi nhánh trước khi cam kết" như bạn đề xuất sẽ hoạt động, nhưng điều đó có thể đòi hỏi nỗ lực thêm từ các nhà phát triển khi họ thực hiện các cam kết, có thể khó bán.

Một cách tiếp cận tương tự có thể dễ dàng hơn là rời khỏi thân cây để mọi người phá vỡ khi họ muốn và có một chi nhánh cho các cam kết không bị phá vỡ. Một tập lệnh tự động có thể đi qua các cam kết khi chúng được tạo ra cho thân cây, chạy thử nghiệm trên chúng và thêm chúng vào nhánh nếu chúng vượt qua.

Hoặc bạn có thể đơn giản một cách vô lý và có một tập lệnh liệt kê các xác nhận chuyển trong một tệp văn bản (có thể hoặc không thể tự kiểm soát phiên bản).

Hoặc có một hệ thống bó chấp nhận các yêu cầu cho các nhánh / phiên bản để kiểm tra (từ bất kỳ nơi nào trên cây), và kiểm tra chúng và cam kết chúng với thân cây (hoặc một nhánh khác) nếu chúng vượt qua.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.