Bạn sử dụng khung tích hợp liên tục nào và tại sao? [đóng cửa]

Có khá nhiều khung tích hợp liên tục (CI) khác nhau và tôi tự hỏi cái nào là phổ biến nhất. Những khuôn khổ nào bạn đã sử dụng tại các công ty nơi bạn làm việc?

Có bất kỳ lý do nào khiến một khung CI phổ biến hơn khung khác - có lẽ điều này liên quan đến các tính năng mà nó cung cấp, những thứ tích hợp vào nó hoặc có thể chỉ là tiếp thị?

Có vẻ như tích hợp liên tục được sử dụng nhiều hơn trong thế giới Java và .net hơn là nói ruby ​​hoặc python. Tại sao lại thế này?

Hudson hoặc Jenkins (cái sau là một ngã ba của cái trước). Lý do: Nó đơn giản (đơn giản để cài đặt và sử dụng) và có tính linh hoạt cao. Các plugin thêm gần như mọi chức năng tôi có thể nghĩ ra.

Vài năm trước tôi đã sử dụng damagecontrol . Nó cũng đơn giản để sử dụng, nhưng không có plugin. Nhưng tác giả đã quyết định rằng ông sẽ từ bỏ giải pháp đơn giản và bắt đầu phát triển một phiên bản mới, bao gồm các máy chủ khác nhau giao tiếp với nhau (cái quái gì vậy?). Điều đó đã không làm việc tốt và dự án đã được từ bỏ. Tôi đã tìm kiếm một thời gian, nhưng cả cruisecontrol (quá phức tạp) hoặc continuum thực sự đã giúp tôi. Cho đến khi hudson, điều đó làm việc từ giây phút đầu tiên đối với tôi.

Tôi sử dụng TeamCity tại nơi làm việc và ở nhà. Nó có sự hỗ trợ tuyệt vời cho nhiều người chạy xây dựng và có thể mở rộng thông qua các plugin.

Không xử lý hàng đống XML cho cấu hình là một điểm cộng rất lớn trong sách của tôi và phiên bản miễn phí là đủ cho nhu cầu nhà của tôi.

Một vấn đề tôi gặp phải với TeamCity là phải cố gắng đưa nó vào phiên bản .NET tự động. Tôi đã phải thiết lập một cách giải quyết tương đối phức tạp, nhưng một khi đã có, nó hoạt động như một cơ duyên.

Cá nhân tôi chỉ sử dụng CruiseControl và CruiseControl.Net. Lý do cho điều này có liên quan đến kinh tế. Chúng ổn định một cách hợp lý và một khi bạn thiết lập chúng, thực sự có rất ít việc bạn cần làm để duy trì nó. Cộng đồng người dùng thường rất hữu ích và có thể mở rộng theo nhu cầu của bạn.

Điều đó nói rằng, có một vài dịch vụ thương mại có sẵn mà tôi biết (một của JetBrains, một của Atlassian) cung cấp trải nghiệm thiết lập tốt hơn và hỗ trợ thương mại. Tôi đã có ý định thử những dịch vụ này nhưng thực sự vẫn chưa có cơ hội.

Các công cụ CI có vai trò quan trọng hơn với các ngôn ngữ được biên dịch so với các ngôn ngữ được dịch, nhưng điều đó không có nghĩa là công cụ CI bị lãng phí đối với các ngôn ngữ được dịch. Khi bạn có một số dự án phụ thuộc lẫn nhau và bạn muốn chắc chắn rằng một thay đổi không vô tình phá vỡ sự phụ thuộc của nó - các công cụ CI là vô giá.

Có ba loại vấn đề chung mà các công cụ CI có thể giúp bạn nắm bắt:

1. Biên dịch lỗi - nếu chữ ký của một lớp thay đổi theo cách phá vỡ các phụ thuộc, tốt nhất bạn nên biết về nó trước giờ tan biến của việc giao hàng.
2. Lỗi logic - nếu hành vi của một lớp thay đổi theo cách phá vỡ sự phụ thuộc, tốt nhất nên biết về nó sớm. Điều này phải được kiểm tra bằng một số loại thử nghiệm tự động, phổ biến nhất là thử nghiệm đơn vị.
3. Kiểm tra chấp nhận - nếu bạn có một bộ kiểm tra tự động để chạy trên sản phẩm hoàn chỉnh, tốt nhất nên chạy chúng thường xuyên.

Các ngôn ngữ được giải thích không được biên dịch, do đó không có lỗi biên dịch để bắt. Tuy nhiên, hai vấn đề khác đủ phổ biến để các công cụ CI hữu ích cho các dự án trong Ruby / Python / Perl / etc.

Từ khóa trong cả lỗi logic và điểm kiểm tra chấp nhận là kiểm tra "tự động". Nếu bạn không có bộ kiểm tra mà máy có thể chạy, thì bạn thực sự đang thiếu những lợi ích lớn hơn của các công cụ CI. Bộ tự động có thể được xây dựng theo thời gian, vì vậy bạn có thể bắt đầu nhỏ.

Chỉnh sửa

Xem biểu đồ đẹp này để so sánh các tính năng của một số lượng lớn Công cụ CI (nhiều trong số đó tôi không biết):

http://confluence.public. Dùtworks.org/display/CC/CI+Feature+Matrix

Nhóm máy chủ nền tảng

CI vững chắc, tích hợp chặt chẽ với Visual Studio và Git làm kiểm soát phiên bản . Tôi đã thấy Máy chủ CI linh hoạt hơn, như Hudson, nhưng sự tích hợp chặt chẽ của TFS với các sản phẩm khác làm cho trải nghiệm trở nên liền mạch đến mức nó có ý nghĩa đối với nhóm của tôi.

Tôi sử dụng cả CruiseControl.NET và Hudson . Một số bản dựng của tôi nằm trên một trong số chúng và một số khác.

Tại sao? Bởi vì tôi không phải là kỹ sư xây dựng và anh ta là kỹ sư xây dựng đã thiết lập chúng theo cách này!

Tôi không gặp vấn đề với cách thiết lập bản dựng của mình hoặc khiếu nại về một trong hai sản phẩm. Tôi đang báo cáo cho bạn cách mọi thứ ở đây, thực tế và hy vọng bạn đánh giá cao quan điểm này!

CẬP NHẬT: Kể từ khi tôi đăng câu trả lời, Hudson đã bị rẽ nhánh và trở thành Jenkins . Các khuyến nghị trên áp dụng cho Jenkins.

Xung . Về cơ bản, nó chỉ hoạt động, mà đối với một kỹ sư xây dựng bận rộn là một vấn đề lớn. Họ cũng có hỗ trợ kỹ thuật thực sự tuyệt vời. Lý do chính tôi yêu thích nó rất nhiều là chúng tôi có hơn 250 dự án và nó xử lý chúng mà không có trục trặc; Tôi không thể nói như vậy với Hudson.

Nhóm của chúng tôi hoạt động chủ yếu bằng Python, C ++ và Java. Chúng tôi sử dụng Buildbot cho CI. Chúng tôi ban đầu đã bắt đầu với nó vì nó tích hợp với Trac và vì nó có vẻ đơn giản và dễ hiểu. Tôi tin rằng đó là khung CI được lựa chọn trong thế giới Python.

Hudson. Đôi khi nó có một chút lỗi và một số plugin thú vị hơn không thực sự hoạt động, nhưng với một chút nắm giữ thì nó khá hữu dụng.

Có lẽ tôi sẽ sử dụng Pulse thay thế, nhưng nếu bạn cần xây dựng trên nhiều nền tảng thì nó> $ 5k, hơi nhiều.

CruiseControl.NET để tích hợp liên tục. Hoạt động khá tốt, mặc dù với số lượng lớn dự án xây dựng mà chúng tôi đã thiết lập trong CruiseControl, ứng dụng khay máy tính để bàn CCTray không phản hồi khủng khiếp, ngay cả với khoảng thời gian làm mới dài.

NAnt dành cho các tập lệnh xây dựng được thực thi trong các dự án CruiseControl. Đối với các tập lệnh xây dựng phức tạp hơn, chúng tôi đã mở rộng NAnt với các tác vụ NA # C tùy chỉnh, rất hay - viết mã bằng C # thú vị hơn nhiều so với tạo tập lệnh NAnt.

Chúng tôi là một cửa hàng của Microsoft và về mặt lý thuyết sẽ chuyển sang Team Build 2010 của Microsoft khi chúng tôi chuyển môi trường Team Foundation Server sang 2010.

Lưu ý rằng bạn sẽ có thể xây dựng ứng dụng của mình từ dòng lệnh bất kể bạn có động cơ CI chạy hay không.

Điều này có nghĩa là tất cả các công cụ CI làm là hệ thống hóa các yêu cầu xây dựng của bạn và bạn có thể chọn công cụ phù hợp nhất với nhu cầu cụ thể của mình.

Về mặt thể chất, tôi thích Hudson chủ yếu vì nó "cảm thấy" tốt, nhưng tôi biết rằng nếu thất bại tôi có thể chuyển sang một cái khác mà không cần quá nhiều nỗ lực. Nếu vậy, có lẽ trước tiên tôi sẽ điều tra cái được tạo bởi Atlassian, vì tôi thích "cảm giác" của các chương trình khác mà họ thực hiện.

Lưu ý rằng khả năng thay thế lẫn nhau ngụ ý rằng chúng không được viết bằng ngôn ngữ nào. Tôi tin rằng Java được chọn cho nhiều công cụ vì nhiều nền tảng được hỗ trợ, kết hợp với nhiều khối xây dựng có sẵn dễ dàng. Cần một máy chủ web - lấy một cái. Cần nhiều chủ đề đồng thời - chỉ cần sử dụng chúng. Cần mở rộng - thả trong một cái lọ.

Trước khi tôi nghe thấy thuật ngữ "tích hợp liên tục" (Điều này đã trở lại vào năm 2002 hoặc 2003), tôi đã viết một kịch bản xây dựng hàng đêm kết nối với cvs, lấy một bản sao sạch của dự án chính và năm dự án nhỏ hơn, xây dựng tất cả jars thông qua ant sau đó được xây dựng và triển khai lại tệp WAR thông qua tập lệnh ant thứ hai sử dụng các tác vụ ant tomcat.

Nó chạy qua cron lúc 7 giờ tối và gửi email với một loạt các tệp đầu ra được đính kèm. Chúng tôi đã sử dụng nó trong toàn bộ 7 tháng của dự án và nó được sử dụng trong 20 tháng tiếp theo để bảo trì và cải tiến.

Nó hoạt động tốt nhưng vẫn thích hudson hơn bash script, cron và ant.