Thiết lập máy chủ tích hợp, tôi nghi ngờ về cách tiếp cận tốt nhất liên quan đến việc sử dụng nhiều tác vụ để hoàn thành bản dựng. Là cách tốt nhất để đặt tất cả chỉ trong một công việc lớn hoặc làm cho những người phụ thuộc nhỏ?Cách tốt nhất để thiết lập máy chủ thử nghiệm tích hợp là gì?
Bạn chắc chắn muốn chia nhỏ các tác vụ. Đây là một ví dụ điển hình về cấu hình CruiseControl.NET có các mục tiêu (nhiệm vụ) khác nhau cho mỗi bước. Nó cũng sử dụng một tập tin common.build có thể được chia sẻ giữa các dự án với ít tùy biến.
http://code.google.com/p/dot-net-reference-app/source/browse/#svn/trunk
Tôi sử dụng TeamCity với tập lệnh xây dựng nant. TeamCity giúp bạn dễ dàng cài đặt phần máy chủ CI và kịch bản xây dựng của nant giúp dễ dàng thực hiện một số tác vụ khi có liên quan đến báo cáo.
Dưới đây là một bài báo tôi đã viết về việc sử dụng CI với CruiseControl.NET, nó có một kịch bản Nant xây dựng trong các ý kiến có thể được tái sử dụng trên các dự án:
Tôi chắc chắn sẽ phá vỡ các công việc. Rất có thể bạn đang có khả năng thực hiện các thay đổi trong bản dựng và sẽ dễ dàng hơn để theo dõi các vấn đề nếu bạn có các tác vụ nhỏ hơn thay vì tìm kiếm thông qua một bản dựng nguyên khối.
Bạn sẽ có thể tạo một công việc lớn từ những phần nhỏ hơn, dù sao đi nữa.
G'day,
Khi bạn đang nói về hội nhập thử nghiệm lớn (rõ ràng) mũi của tôi sẽ làm cho các máy chủ thử nghiệm xây dựng và cấu hình càng gần càng tốt đến môi trường triển khai như khả thi.
</thebloodyobvious> (-:
cổ vũ, Rob
Phương pháp tôi ủng hộ là thiết lập sau (Trên thực tế giả sử bạn đang ở trong một dự án NET):
Trên nhiều dự án bạn thấy rằng có những cấp độ khác nhau của các bài kiểm tra và các hoạt động đó diễn ra khi ai đó làm một checkin. Đôi khi những điều này có thể tăng theo thời gian đến mức có thể là một thời gian dài sau khi xây dựng trước khi một nhà phát triển có thể xem liệu họ có phá vỡ bản dựng bằng một lần đăng ký hay không.
Những gì tôi làm trong những trường hợp này là tạo ra ba xây dựng (hoặc có thể hai):
Điều quan trọng về bất kỳ hệ thống CI là nó cần phải hữu cơ và liên tục được tinh chỉnh. Có một số phần mở rộng tuyệt vời cho CruiseControl.NET có nhật ký và biểu đồ xây dựng timings vv cho các bước và cho phép bạn phân tích lịch sử và vì vậy cho phép bạn liên tục tinh chỉnh các bản dựng để giữ chúng linh hoạt. Đó là một cái gì đó mà các nhà quản lý thấy khó chấp nhận rằng một hộp xây dựng có thể sẽ giữ cho bạn bận rộn cho một phần năm thời gian làm việc của bạn chỉ để ngăn chặn nó ngừng lại.
Chúng tôi sử dụng buildbot, với bản dựng được chia thành các bước riêng biệt. Có một sự cân bằng được tìm thấy giữa việc xây dựng các bước được chia nhỏ với độ chi tiết đủ và là một đơn vị hoàn chỉnh.
Ví dụ ở vị trí hiện tại của tôi, chúng tôi xây dựng các phần con cho mỗi nền tảng của chúng tôi (Mac, Linux, Windows) trên nền tảng tương ứng của chúng. Sau đó chúng tôi có một bước (với một vài bước phụ) mà biên dịch chúng thành phiên bản cuối cùng sẽ kết thúc trong các bản phân phối cuối cùng.
Nếu xảy ra sự cố trong bất kỳ bước nào trong số các bước đó, bạn sẽ dễ dàng chẩn đoán.
Lời khuyên của tôi là viết các bước trên bảng trắng theo các thuật ngữ mơ hồ nhất có thể và sau đó căn cứ vào các bước của bạn. Trong trường hợp của tôi đó sẽ là:
Phá nhiệm vụ của bạn lên rời rạc mục tiêu/hoạt động, sau đó sử dụng một kịch bản cấp cao hơn để buộc chúng lại với nhau một cách thích hợp.
Điều này làm cho quy trình xây dựng của bạn dễ hiểu hơn cho người khác (bạn đang làm tài liệu khi bạn đi để bất kỳ ai trong nhóm của bạn có thể nhặt nó lên, phải không?), Cũng như tăng khả năng tái sử dụng. Có thể bạn sẽ không sử dụng lại các kịch bản cấp cao (mặc dù điều này có thể xảy ra nếu bạn có dự án tương tự), nhưng bạn chắc chắn có thể sử dụng lại (ngay cả khi sao chép/dán) các hoạt động rời rạc khá dễ dàng.
Hãy xem xét ví dụ về việc nhận nguồn mới nhất từ kho lưu trữ của bạn. Bạn sẽ muốn nhóm các nhiệm vụ/hoạt động để lấy mã bằng một số câu lệnh ghi nhật ký và tham khảo thông tin tài khoản thích hợp. Đây là một thứ rất dễ sử dụng từ dự án này đến dự án tiếp theo.Đối với môi trường của nhóm chúng tôi, chúng tôi sử dụng NAnt vì nó cung cấp môi trường kịch bản phổ biến giữa các máy dev (nơi chúng tôi viết/gỡ lỗi các script) và máy chủ CI (vì chúng tôi chỉ thực thi cùng một kịch bản trong môi trường trong sạch). Chúng tôi sử dụng Jenkins để quản lý các bản dựng của chúng tôi, nhưng ở mỗi lõi của họ, mỗi dự án chỉ cần gọi vào các kịch bản NAnt tương tự và sau đó chúng tôi thao tác các kết quả (ví dụ, lưu trữ kết quả xây dựng, kiểm tra lỗi cờ).