Làm thế nào để bạn mở rộng quy mô kiểm tra tích hợp của bạn?

Tôi đang nghiên cứu các kỹ thuật và chiến lược để nhân rộng số lượng thử nghiệm tích hợp ngày càng tăng trên sản phẩm hiện tại của chúng tôi, để chúng có thể (một cách nhân văn) vẫn là một phần của quá trình phát triển của chúng tôi và quá trình CI.

Tại khoảng hơn 200 thử nghiệm tích hợp, chúng tôi đã đạt mốc 1 giờ để hoàn thành quá trình chạy thử hoàn chỉnh (trên máy aa dành cho máy tính để bàn) và điều này ảnh hưởng tiêu cực đến khả năng của nhà phát triển trong việc chấp nhận chạy toàn bộ bộ phần mềm như một phần của quy trình đẩy thông thường. Điều này đang ảnh hưởng đến động lực để được kỷ luật về việc tạo ra chúng tốt. Chúng tôi chỉ tích hợp thử nghiệm các khung cảnh chính từ trước ra sau và chúng tôi sử dụng một môi trường phản chiếu việc sản xuất, được xây dựng từ đầu mỗi lần chạy thử.

Bởi vì thời gian cần thiết để chạy, nó đang tạo ra một vòng phản hồi khủng khiếp và nhiều chu kỳ lãng phí đang chờ trên máy để hoàn thành các lần chạy thử, bất kể việc chạy thử có tập trung đến mức nào. Không bao giờ tác động tiêu cực đắt tiền hơn đối với dòng chảy và tiến độ, sự tỉnh táo và bền vững.

Chúng tôi hy vọng sẽ có các bài kiểm tra tích hợp gấp 10 lần trước khi sản phẩm này bắt đầu chậm lại (thực sự không có ý tưởng nào, nhưng có vẻ như chúng tôi thậm chí chưa bắt đầu về các tính năng). Chúng tôi phải mong đợi một cách hợp lý là trong vài trăm hoặc vài nghìn bài kiểm tra tích hợp, tôi nghĩ rằng tại một số điểm.

Để rõ ràng, để cố gắng ngăn điều này trở thành một cuộc thảo luận về thử nghiệm đơn vị so với thử nghiệm tích hợp, (không bao giờ nên giao dịch). Chúng tôi đang thực hiện cả thử nghiệm đơn vị với thử nghiệm tích hợp TDD VÀ trong sản phẩm này. Trên thực tế, chúng tôi thực hiện kiểm tra tích hợp ở các lớp khác nhau trong kiến ​​trúc dịch vụ mà chúng tôi có, nơi có ý nghĩa với chúng tôi, vì chúng tôi cần xác minh nơi chúng tôi giới thiệu các thay đổi đột phá khi thay đổi các mẫu trong kiến ​​trúc của chúng tôi sang các khu vực khác của hệ thống. 

Một chút về ngăn xếp công nghệ của chúng tôi. Chúng tôi hiện đang thử nghiệm trên môi trường mô phỏng (CPU và bộ nhớ) để chạy thử nghiệm từ đầu đến cuối. Bao gồm các dịch vụ web Azure REST có phần phụ trợ noSql (ATS). Chúng tôi đang mô phỏng môi trường sản xuất của mình bằng cách chạy trong Trình mô phỏng máy tính để bàn Azure + IISExpress. Chúng tôi giới hạn ở một trình giả lập và một kho lưu trữ phụ trợ cục bộ trên mỗi máy dev.

Chúng tôi cũng có CI dựa trên đám mây, chạy thử nghiệm tương tự trong cùng môi trường giả lập và quá trình chạy thử nghiệm mất gấp đôi thời gian (2hrs +) trong đám mây với nhà cung cấp CI hiện tại của chúng tôi. Chúng tôi đã đạt đến giới hạn của nhà cung cấp CI đám mây SLA về hiệu suất phần cứng và vượt quá mức cho phép của họ về thời gian chạy thử nghiệm. Công bằng với họ, thông số kỹ thuật của họ không phải là xấu, nhưng tốt bằng một nửa so với một máy tính để bàn càu nhàu rõ ràng.

Chúng tôi đang sử dụng chiến lược thử nghiệm để xây dựng lại kho lưu trữ dữ liệu của mình cho từng nhóm thử nghiệm logic và tải trước dữ liệu thử nghiệm. Mặc dù bảo đảm toàn vẹn dữ liệu toàn diện, nhưng điều này tăng thêm 5-15% tác động cho mỗi thử nghiệm. Vì vậy, chúng tôi nghĩ rằng có rất ít để đạt được tối ưu hóa chiến lược thử nghiệm tại thời điểm này trong phát triển sản phẩm. 

Điểm dài và ngắn của nó là: trong khi chúng tôi có thể tối ưu hóa thông lượng của mỗi thử nghiệm (ngay cả khi có đến 30% -50% mỗi thử nghiệm), chúng tôi vẫn sẽ không mở rộng hiệu quả trong tương lai gần với hàng trăm thử nghiệm. 1 giờ bây giờ thậm chí còn vượt quá khả năng chịu đựng của con người, chúng ta cần một trật tự cải thiện cường độ trong quy trình tổng thể để làm cho nó bền vững.

Vì vậy, tôi đang nghiên cứu những kỹ thuật và chiến lược nào chúng ta có thể sử dụng để giảm đáng kể thời gian thử nghiệm.

• Viết ít bài kiểm tra không phải là một lựa chọn. Xin vui lòng không tranh luận rằng một trong chủ đề này.
• Sử dụng phần cứng nhanh hơn chắc chắn là một lựa chọn, mặc dù rất tốn kém.
• Chạy các nhóm thử nghiệm / kịch bản trên phần cứng riêng biệt song song cũng chắc chắn là một lựa chọn ưu tiên.
• Tạo nhóm các thử nghiệm xung quanh các tính năng và kịch bản đang được phát triển là hợp lý, nhưng cuối cùng không đáng tin cậy trong việc chứng minh phạm vi bảo hiểm đầy đủ hoặc sự tự tin rằng hệ thống không bị ảnh hưởng bởi một thay đổi. 
• Chạy trong môi trường dàn dựng trên nền tảng đám mây thay vì chạy trong trình giả lập máy tính để bàn là có thể về mặt kỹ thuật, mặc dù chúng tôi bắt đầu thêm thời gian triển khai để chạy thử (mỗi lần 20 phút khi bắt đầu chạy thử để triển khai nội dung).
• Việc chia các thành phần của hệ thống thành các phần logial độc lập có thể hợp lý ở một mức độ nào đó, nhưng chúng tôi hy vọng số dặm giới hạn trên đó, vì sự tương tác giữa các thành phần dự kiến ​​sẽ tăng theo thời gian. (tức là một sự thay đổi có khả năng ảnh hưởng đến những người khác theo những cách không mong muốn - như thường xảy ra khi một hệ thống được phát triển gia tăng)

Tôi muốn xem những chiến lược (và công cụ) nào mà người khác đang sử dụng trong không gian này.

(Tôi phải tin rằng những người khác có thể đang gặp loại khó khăn này khi sử dụng các bộ công nghệ nhất định.))

[Cập nhật: 16/12/2016: Chúng tôi cuối cùng đã đầu tư nhiều hơn vào thử nghiệm song song CI, để thảo luận về kết quả: http://www.mindkin.co.nz/blog/2015/12/16/16-jobs]

Tôi đã làm việc tại một nơi mất 5 giờ (trên 30 máy) để chạy thử nghiệm tích hợp. Tôi đã cấu trúc lại codebase và thực hiện các bài kiểm tra đơn vị thay cho các công cụ mới. Các bài kiểm tra đơn vị mất 30 giây (trên 1 máy). Oh, và lỗi cũng đi xuống. Và thời gian phát triển kể từ khi chúng tôi biết chính xác những gì đã phá vỡ với các bài kiểm tra chi tiết.

Câu chuyện dài, bạn không. Các thử nghiệm tích hợp đầy đủ tăng theo cấp số nhân khi codebase của bạn phát triển (nhiều mã hơn có nghĩa là nhiều thử nghiệm hơn và nhiều mã hơn có nghĩa là tất cả các thử nghiệm mất nhiều thời gian hơn để chạy khi có nhiều "tích hợp" hơn để hoạt động). Tôi sẽ lập luận rằng bất cứ điều gì trong phạm vi "giờ" sẽ mất hầu hết các lợi ích của việc tích hợp liên tục vì vòng phản hồi không có ở đó. Ngay cả một trật tự cải thiện cường độ cũng không đủ để giúp bạn trở nên tốt hơn - và không nơi nào có thể giúp bạn mở rộng được.

Vì vậy, tôi khuyên bạn nên cắt các bài kiểm tra tích hợp xuống các bài kiểm tra khói quan trọng nhất, rộng nhất. Sau đó, chúng có thể được chạy hàng đêm hoặc một số khoảng thời gian ít hơn liên tục, giảm phần lớn nhu cầu về hiệu suất của bạn. Các thử nghiệm đơn vị, chỉ phát triển tuyến tính khi bạn thêm nhiều mã hơn (các thử nghiệm tăng, thời gian chạy thử nghiệm không) là cách để đi theo tỷ lệ.

Các bài kiểm tra tích hợp sẽ luôn hoạt động lâu vì chúng nên bắt chước một người dùng thực sự. Vì lý do này, bạn không nên chạy tất cả chúng một cách đồng bộ!

Cho rằng bạn đang chạy công cụ trên đám mây, có vẻ như tôi đang ở vị trí đắc địa để mở rộng các bài kiểm tra của mình qua nhiều máy.

Trong trường hợp cực đoan, hãy tạo ra một môi trường mới cho mỗi thử nghiệm và chạy tất cả chúng cùng một lúc. Các bài kiểm tra tích hợp của bạn sau đó sẽ chỉ mất chừng nào bài kiểm tra chạy dài nhất.

Cắt giảm / tối ưu hóa các thử nghiệm có vẻ là ý tưởng tốt nhất với tôi, nhưng trong trường hợp đó không phải là một lựa chọn, tôi có một cách khác để đề xuất (nhưng yêu cầu xây dựng một số công cụ độc quyền đơn giản).

Tôi đã đối mặt với một vấn đề tương tự nhưng không phải trong các bài kiểm tra tích hợp của chúng tôi (những bài này chạy trong vài phút). Thay vào đó, nó chỉ đơn giản là trong các bản dựng của chúng tôi: cơ sở mã C quy mô lớn, sẽ mất nhiều giờ để xây dựng.

Điều tôi thấy vô cùng lãng phí là thực tế là chúng tôi đã xây dựng lại toàn bộ từ đầu (khoảng 20.000 tệp nguồn / đơn vị biên dịch) ngay cả khi chỉ một vài tệp nguồn thay đổi, và do đó mất hàng giờ để thay đổi chỉ mất vài giây hoặc vài phút lúc tồi tệ nhất.

Vì vậy, chúng tôi đã thử liên kết gia tăng trên các máy chủ xây dựng của mình, nhưng điều đó không đáng tin cậy. Đôi khi nó sẽ đưa ra những tiêu cực sai và không xây dựng trên một số cam kết, chỉ sau đó thành công trên một bản dựng lại hoàn chỉnh. Tồi tệ hơn, đôi khi nó sẽ cho kết quả dương tính giả và báo cáo thành công xây dựng, chỉ dành cho nhà phát triển hợp nhất một bản dựng bị hỏng vào nhánh chính. Vì vậy, chúng tôi đã quay lại để xây dựng lại mọi thứ mỗi khi nhà phát triển thúc đẩy thay đổi từ chi nhánh riêng của mình.

Tôi ghét điều này rất nhiều. Tôi sẽ đi vào phòng hội thảo với một nửa các nhà phát triển chơi trò chơi điện tử và đơn giản vì có rất ít việc phải làm trong khi chờ đợi các bản dựng. Tôi đã cố gắng để có được lợi thế về năng suất bằng cách đa nhiệm và bắt đầu một chi nhánh mới sau khi tôi cam kết để tôi có thể làm việc với mã trong khi chờ các bản dựng, nhưng khi thử nghiệm hoặc xây dựng thất bại, việc xếp hàng thay đổi qua điểm đó đã trở nên quá đau đớn và cố gắng sửa chữa mọi thứ và khâu lại tất cả.

Dự án phụ trong khi chờ đợi, tích hợp sau

Vì vậy, những gì tôi đã làm thay vào đó là tạo một khung xương của ứng dụng - cùng loại UI cơ bản và các phần có liên quan của SDK để tôi phát triển dựa trên toàn bộ dự án riêng biệt. Sau đó, tôi sẽ viết mã độc lập chống lại điều đó trong khi chờ xây dựng, bên ngoài dự án chính. Điều đó ít nhất đã cho tôi một số mã hóa để làm cho tôi có thể duy trì năng suất, và sau đó tôi sẽ bắt đầu tích hợp công việc đó được thực hiện hoàn toàn bên ngoài sản phẩm vào đoạn mã sau của dự án. Đó là một chiến lược cho các nhà phát triển của bạn nếu họ thấy mình chờ đợi rất nhiều.

Phân tích tệp nguồn theo cách thủ công để tìm hiểu những gì cần xây dựng lại / chạy lại

Tuy nhiên, tôi ghét cách chúng ta lãng phí quá nhiều thời gian để xây dựng lại mọi thứ mọi lúc. Vì vậy, tôi đã tự mình lấy một vài ngày cuối tuần để viết một số mã thực sự sẽ quét các tệp để thay đổi và chỉ xây dựng lại các dự án có liên quan - vẫn là một bản dựng lại đầy đủ, không liên kết gia tăng, mà chỉ các dự án cần được xây dựng lại ( có tệp phụ thuộc, được phân tích cú pháp đệ quy, đã thay đổi). Điều đó hoàn toàn đáng tin cậy và sau khi chứng minh và thử nghiệm nó một cách triệt để, chúng tôi đã có thể sử dụng giải pháp đó. Điều đó đã cắt giảm thời gian xây dựng trung bình từ vài giờ xuống vài phút vì chúng tôi chỉ xây dựng lại các dự án cần thiết (mặc dù các thay đổi SDK trung tâm vẫn có thể mất một giờ, nhưng chúng tôi đã làm điều đó ít thường xuyên hơn so với thay đổi cục bộ).

Chiến lược tương tự nên được áp dụng cho các bài kiểm tra tích hợp. Chỉ cần phân tích cú pháp các tệp nguồn để tìm ra các tệp mà các kiểm tra tích hợp phụ thuộc vào (ví dụ: importtrong Java,#includetrong C hoặc C ++) ở phía máy chủ và các tệp được bao gồm / được nhập từ các tệp đó, v.v., xây dựng một biểu đồ tệp phụ thuộc bao gồm / nhập đầy đủ cho hệ thống. Không giống như phân tích cú pháp xây dựng tạo thành DAG, biểu đồ sẽ không bị ảnh hưởng vì nó quan tâm đến bất kỳ tệp nào thay đổi có chứa mã có thể được thực thi gián tiếp *. Chỉ chạy lại kiểm tra tích hợp nếu bất kỳ tệp nào trong biểu đồ cho kiểm tra tích hợp quan tâm đã thay đổi. Ngay cả đối với hàng triệu dòng mã, thật dễ dàng để thực hiện phân tích cú pháp này trong vòng chưa đầy một phút. Nếu bạn có các tệp không phải là mã nguồn có thể ảnh hưởng đến kiểm tra tích hợp, như các tệp nội dung, có lẽ bạn có thể viết siêu dữ liệu vào một nhận xét trong mã nguồn cho biết các phụ thuộc đó trong các kiểm tra tích hợp, do đó các tệp bên ngoài đó cũng thay đổi. được chạy lại.

_{* Ví dụ: nếu test.c bao gồm foo.h cũng được bao gồm bởi foo.c, thì một thay đổi đối với test.c, foo.h hoặc foo.c sẽ đánh dấu kiểm tra tích hợp là cần chạy mới.}

Việc này có thể mất cả một hoặc hai ngày để lập trình và thử nghiệm, đặc biệt là trong môi trường chính thức, nhưng tôi nghĩ nên làm việc ngay cả đối với các bài kiểm tra tích hợp và nó hoàn toàn xứng đáng nếu bạn không có lựa chọn nào khác ngoài việc chờ đợi trong phạm vi giờ để xây dựng để kết thúc (do quá trình xây dựng hoặc thử nghiệm hoặc đóng gói hoặc bất cứ điều gì). Điều đó có thể chuyển thành rất nhiều manhours bị mất chỉ trong vài tháng sẽ làm giảm thời gian cần thiết để xây dựng giải pháp độc quyền này, cũng như giết chết năng lượng của đội và làm tăng căng thẳng do xung đột trong các vụ sáp nhập lớn hơn được thực hiện ít hơn thường xuyên như là kết quả của tất cả thời gian chờ đợi lãng phí. Điều đó chỉ tệ cho toàn đội khi họ dành phần lớn thời gian để chờ đợi mọi thứ.mọi thứ sẽ được xây dựng lại / chạy lại / đóng gói lại trên mỗi thay đổi nhỏ.

Âm thanh như bạn có quá nhiều bài kiểm tra tích hợp. Nhớ lại kim tự tháp . Kiểm tra tích hợp thuộc về giữa.

Như một ví dụ lấy một kho lưu trữ với phương thức set(key,object), get(key). Kho lưu trữ này được sử dụng rộng rãi trong toàn bộ cơ sở mã của bạn. Tất cả các phương pháp phụ thuộc vào kho lưu trữ này sẽ được kiểm tra với kho lưu trữ giả. Bây giờ bạn chỉ cần hai bài kiểm tra tích hợp, một cho bộ và một để nhận.

Một số thử nghiệm tích hợp có thể có thể được chuyển đổi thành thử nghiệm đơn vị. Ví dụ: các thử nghiệm từ đầu đến cuối trong chế độ xem của tôi chỉ nên kiểm tra xem trang web có được cấu hình đúng với chuỗi kết nối chính xác và tên miền chính xác hay không.

Kiểm tra tích hợp nên kiểm tra rằng ORM, kho lưu trữ và trừu tượng hàng đợi là chính xác. Theo nguyên tắc thông thường, không cần mã miền để kiểm tra tích hợp - chỉ trừu tượng hóa.

Hầu hết mọi thứ khác có thể được kiểm tra đơn vị với các cài đặt gốc / mocked / giả / in-mem cho các phụ thuộc.

Theo kinh nghiệm của tôi trong môi trường Agile hoặc DevOps nơi các đường ống phân phối liên tục là phổ biến, nên tiến hành kiểm tra tích hợp khi mỗi mô-đun được hoàn thành hoặc điều chỉnh. Ví dụ, trong nhiều môi trường đường ống phân phối liên tục, không có gì lạ khi có nhiều triển khai mã cho mỗi nhà phát triển mỗi ngày. Chạy một tập hợp nhanh các thử nghiệm tích hợp vào cuối mỗi giai đoạn phát triển trước khi triển khai phải là một thông lệ tiêu chuẩn trong loại môi trường này. Để biết thêm thông tin, một Sách điện tử tuyệt vời để đưa vào bài đọc của bạn về chủ đề này là Hướng dẫn thực hành để kiểm tra trong DevOps , được viết bởi Katrina Clokie.

Để kiểm tra hiệu quả theo cách này, thành phần mới phải được kiểm tra đối với các mô-đun đã hoàn thành hiện có trong môi trường thử nghiệm chuyên dụng hoặc chống lại Stub và Trình điều khiển. Tùy thuộc vào nhu cầu của bạn, nói chung nên giữ một thư viện Sơ đồ và Trình điều khiển cho mỗi mô-đun ứng dụng trong một thư mục hoặc thư viện để cho phép sử dụng thử nghiệm Tích hợp lặp lại nhanh chóng. Giữ Stub và Trình điều khiển được tổ chức như thế này giúp dễ dàng thực hiện các thay đổi lặp lại, giữ cho chúng được cập nhật và thực hiện tối ưu để đáp ứng nhu cầu thử nghiệm liên tục của bạn.

Một lựa chọn khác để xem xét là một giải pháp ban đầu được phát triển vào khoảng năm 2002, được gọi là Dịch vụ ảo hóa. Điều này tạo ra một môi trường ảo, mô phỏng tương tác mô-đun với các tài nguyên hiện có cho mục đích thử nghiệm trong môi trường DevOps doanh nghiệp phức tạp hoặc môi trường Agile.

Bài viết này có thể hữu ích để hiểu thêm về cách thực hiện kiểm tra tích hợp trong doanh nghiệp

Bạn đã đo từng bài kiểm tra để xem thời gian đang được thực hiện chưa? Và sau đó, đo hiệu suất của cơ sở mã nếu có một bit đặc biệt chậm. Là vấn đề tổng thể là một trong những thử nghiệm hoặc triển khai, hoặc cả hai?

Thông thường, bạn muốn giảm tác động của kiểm tra tích hợp để việc chạy chúng trên các thay đổi tương đối nhỏ được giảm thiểu. Sau đó, bạn có thể để lại bài kiểm tra đầy đủ cho lần chạy 'QA' mà bạn thực hiện khi nhánh được thăng cấp lên cấp độ tiếp theo. Vì vậy, bạn có các bài kiểm tra đơn vị cho các nhánh dev, chạy các kiểm thử tích hợp giảm khi được hợp nhất và chạy thử nghiệm tích hợp đầy đủ khi được hợp nhất với một nhánh ứng viên phát hành.

Vì vậy, điều này có nghĩa là bạn không phải xây dựng lại và đóng gói lại và triển khai lại mọi thứ mỗi lần cam kết. Bạn có thể tổ chức thiết lập của mình, trong môi trường dev, để thực hiện triển khai càng rẻ càng tốt, tin tưởng rằng nó sẽ ổn. Thay vì quay toàn bộ VM và triển khai toàn bộ sản phẩm, hãy để VM với phiên bản cũ tại chỗ và sao chép các tệp nhị phân mới tại chỗ, ví dụ (YMMV tùy thuộc vào những gì bạn phải làm).

Cách tiếp cận lạc quan tổng thể này vẫn yêu cầu thử nghiệm đầy đủ, nhưng điều đó có thể được thực hiện ở giai đoạn sau khi thời gian thực hiện ít khẩn cấp hơn. (ví dụ: bạn có thể chạy thử nghiệm đầy đủ một lần trong đêm, nếu có bất kỳ vấn đề nào nhà phát triển có thể giải quyết chúng vào buổi sáng). Điều này cũng có lợi thế là làm mới sản phẩm trên giàn tích hợp cho thử nghiệm vào ngày hôm sau - nó có thể bị lỗi thời khi các nhà phát triển thay đổi mọi thứ, nhưng chỉ sau 1 ngày.

Chúng tôi đã có một vấn đề tương tự khi chạy một công cụ phân tích tĩnh dựa trên bảo mật. Việc chạy đầy đủ sẽ mất nhiều thời gian, vì vậy chúng tôi đã chuyển nó từ nhà phát triển cam kết sang một cam kết tích hợp (nghĩa là chúng tôi có một hệ thống mà nhà phát triển nói rằng họ đã hoàn thành, nó đã được sáp nhập vào một nhánh 'cấp 2', nơi thực hiện nhiều thử nghiệm hơn, bao gồm cả sự hoàn hảo Khi hoàn thành, nó đã được sáp nhập vào một nhánh QA để triển khai. Ý tưởng là loại bỏ các hoạt động thường xuyên sẽ diễn ra liên tục để chạy được thực hiện hàng đêm - các nhà phát triển sẽ nhận được kết quả vào buổi sáng và chúng sẽ không ảnh hưởng đến sự phát triển của họ tập trung cho đến sau này trong chu kỳ dev của họ).

Tại một số điểm, một bộ đầy đủ các bài kiểm tra tích hợp có thể mất nhiều giờ để hoàn thành, ngay cả trên phần cứng đắt tiền. Một trong các tùy chọn là không chạy phần lớn các thử nghiệm đó trên mỗi lần xác nhận, và thay vào đó chạy chúng mỗi đêm hoặc trong chế độ hàng loạt liên tục (một lần cho mỗi lần xác nhận).

Tuy nhiên, điều này tạo ra một vấn đề mới - các nhà phát triển không nhận được phản hồi ngay lập tức và các bản dựng bị hỏng có thể không được chú ý. Để khắc phục điều này, điều quan trọng là họ sẽ biết rằng một cái gì đó bị hỏng mọi lúc. Xây dựng các công cụ thông báo như trình thông báo khay của Catlight hoặc TeamCity có thể khá hữu ích.

Nhưng sẽ có một vấn đề khác. Ngay cả khi nhà phát triển thấy rằng bản dựng bị hỏng, anh ta có thể không vội kiểm tra nó. Rốt cuộc, ai đó có thể đã kiểm tra nó, phải không?

Vì lý do đó, hai công cụ đó có tính năng "điều tra xây dựng". Nó sẽ cho biết nếu có ai trong nhóm phát triển thực sự kiểm tra và sửa chữa bản dựng bị hỏng. Các nhà phát triển có thể tình nguyện kiểm tra bản dựng và cho đến khi điều đó xảy ra, mọi người trong nhóm sẽ khó chịu bởi một biểu tượng màu đỏ gần đồng hồ.

Có vẻ như cơ sở mã của bạn đang phát triển lớn và một số quản lý mã sẽ giúp đỡ. Chúng tôi sử dụng Java, vì vậy xin lỗi trước nếu tôi giả sử điều này.

• Một dự án lớn cần được chia thành các dự án riêng lẻ nhỏ hơn để biên dịch cho các thư viện. Các công cụ Java như nexus làm cho điều này trở nên dễ dàng.
• Mỗi thư viện nên thực hiện một giao diện. Điều này hỗ trợ khai thác thư viện trong các bài kiểm tra cấp cao hơn. Điều này đặc biệt hữu ích nếu thư viện truy cập cơ sở dữ liệu hoặc kho dữ liệu bên ngoài (ví dụ: máy tính lớn). Trong những trường hợp như vậy, việc đưa dữ liệu máy tính lớn hoặc cơ sở dữ liệu vào trạng thái lặp lại có thể sẽ chậm và có thể là không thể.
• Kiểm tra tích hợp cho mỗi thư viện có thể là toàn diện, nhưng chỉ cần chạy khi nguồn thư viện mới được cam kết.
• Các bài kiểm tra tích hợp cấp cao hơn chỉ nên gọi các thư viện và cho rằng chúng hoàn hảo.

Cửa hàng Java mà tôi làm việc sử dụng cách tiếp cận này và chúng tôi hiếm khi chờ đợi các thử nghiệm tích hợp chạy.

Một cách tiếp cận khả thi khác để duy trì các thử nghiệm tích hợp đường ống CI (hoặc bất kỳ loại xác minh nào, bao gồm cả bản dựng) với thời gian thực hiện dài hoặc yêu cầu tài nguyên hạn chế và / hoặc đắt tiền là chuyển từ hệ thống CI truyền thống dựa trên xác minh sau cam kết (đó là dễ bị tắc nghẽn ) dựa trên xác minh trước khi xác nhận.

Thay vì trực tiếp cam kết các thay đổi của họ vào các nhà phát triển chi nhánh, hãy gửi chúng đến một hệ thống xác minh tự động tập trung để thực hiện các xác minh và:

• nếu thành công, nó tự động cam kết các thay đổi vào chi nhánh
• nếu không thành công, nó sẽ thông báo cho người nộp tương ứng để đánh giá lại các thay đổi của họ

Cách tiếp cận như vậy cho phép kết hợp và thử nghiệm nhiều thay đổi được gửi, có khả năng tăng tốc độ xác minh CI hiệu quả lên nhiều lần.

Một ví dụ như vậy là hệ thống gating dựa trên Gerrit / Zuul được sử dụng bởi OpenStack .

Một cái khác là ApartCI ( từ chối trách nhiệm - Tôi là người tạo ra nó và là người sáng lập công ty cung cấp nó).