Tại điểm nào là một máy chủ tích hợp liên tục thú vị?


9

Tôi đã đọc một chút về các máy chủ CI như Jenkins và tôi tự hỏi: nó hữu ích ở điểm nào?

Bởi vì chắc chắn đối với một dự án nhỏ mà bạn chỉ có 5 lớp và 10 bài kiểm tra đơn vị, không có nhu cầu thực sự.

Tại đây, chúng tôi đã có khoảng 1500 bài kiểm tra đơn vị và chúng đã vượt qua (trên các máy trạm Core 2 Duo cũ) trong khoảng 90 giây (vì chúng thực sự đang thử nghiệm "đơn vị" và do đó rất nhanh). Quy tắc chúng tôi có là chúng tôi không thể cam kết mã khi thử nghiệm thất bại.

Vì vậy, mỗi nhà phát triển khởi chạy tất cả các thử nghiệm của mình để ngăn chặn hồi quy.

Rõ ràng, bởi vì tất cả các nhà phát triển luôn khởi chạy tất cả các thử nghiệm mà chúng tôi gặp phải do các thay đổi mâu thuẫn ngay khi một nhà phát triển thực hiện thay đổi của một nhà phát triển khác (khi có).

Tôi vẫn chưa rõ lắm: tôi có nên thiết lập máy chủ CI như Jenkins không? Nó sẽ mang lại điều gì?

Có phải nó chỉ hữu ích cho việc tăng tốc? (không phải là một vấn đề trong trường hợp của chúng tôi)

Có hữu ích vì các bản dựng cũ có thể được tạo lại? (nhưng chúng ta có thể làm điều này với Mercurial, bằng cách kiểm tra các vòng quay cũ)

Về cơ bản tôi hiểu nó có thể hữu ích nhưng tôi không biết chính xác tại sao.

Bất kỳ lời giải thích nào có tính đến các điểm tôi nêu ở trên sẽ được hoan nghênh nhất.

Câu trả lời:


9

Có phải nó chỉ hữu ích cho việc tăng tốc? (không phải là một vấn đề trong trường hợp của chúng tôi)

Bất kỳ thời gian nào dành cho việc đạp xe, quá trình của bạn là thời gian bạn có thể dành để tham gia vào quá trình phát triển.

Bạn cũng sẽ tiết kiệm thời gian tại các mốc quan trọng vì lý tưởng nhất là bạn đang xây dựng các bit được đóng gói đầy đủ và sẵn sàng để có thể ghi thẳng vào CD, tải lên web, v.v.

Có hữu ích vì các bản dựng cũ có thể được tạo lại? (nhưng chúng ta có thể làm điều này với Mercurial, bằng cách kiểm tra các vòng quay cũ)

Không, bạn không tạo lại các bản dựng. Bạn sử dụng bản dựng được tạo và giữ nó cho đến khi cài đặt duy trì của bạn ném nó ra.

Bạn xây dựng nó trên máy chủ xây dựng, trái ngược với hộp của Dev.

Tại đây, chúng tôi đã có khoảng 1500 bài kiểm tra đơn vị và chúng đã vượt qua (trên các máy trạm Core 2 Duo cũ) trong khoảng 90 giây (vì chúng thực sự đang thử nghiệm "đơn vị" và do đó rất nhanh). Quy tắc chúng tôi có là chúng tôi không thể cam kết mã khi thử nghiệm thất bại.

Ngoài ra, bạn có muốn chạy tích hợp tự động hoặc kiểm tra đầu cuối trên mã của mình và nắm bắt các vấn đề mà các bài kiểm tra đơn vị sẽ không bắt được không?

Bạn sẽ không muốn chạy chúng trên các hộp dev, vì sẽ rất khó để thiết lập và duy trì môi trường đó. Kiểm tra tích hợp cũng có xu hướng rất chậm để thực hiện.

tại điểm nào là hữu ích?

Đó là một khoản đầu tư như bất kỳ khác.

Sử dụng một lần và bạn có thể đi ra phía sau hoặc chỉ hòa vốn. Sử dụng nó trên nhiều dự án và bạn có thể sẽ đi ra phía trước.

Nó cũng phụ thuộc vào loại ứng dụng bạn thực hiện.

Nếu bạn tạo các ứng dụng web cần được triển khai cho Máy chủ ứng dụng Java hoặc IIS, thì CI sẽ trở thành không có trí tuệ. Tương tự nếu bạn có một cơ sở dữ liệu như là một phần của dự án của bạn. Triển khai là khó khăn để thực hiện thủ công và nhóm QA của bạn (nếu bạn có) sẽ cần nó thường xuyên như hàng ngày tại một số điểm.

Ngoài ra, bạn có thể muốn xem nhu cầu và vấn đề của mình phù hợp với 12 bước để mã tốt hơn của Joel Spolsky . Đặc biệt là 2, 3 và 10 (mặc dù chúng đều thú vị và quan trọng).


2
+1 ... OK bây giờ bạn đang nói chuyện với tôi! Đối số "không mất thời gian thực hiện các bản dựng" tôi rất thích. Quá trình xây dựng của chúng tôi được thực hiện nhiều lần mỗi ngày và chỉ mất một cú nhấp chuột nhưng ... nó chậm hơn so với việc chạy tất cả các bài kiểm tra (vì vậy các nhà phát triển đang mất thời gian). Ngoài ra, tôi thích ý tưởng về các thử nghiệm phức tạp hơn: điều này tôi thấy làm thế nào chúng ta có thể hưởng lợi từ máy chủ CI. Về 2,3 và 10: có, có và có (một lần nhấp vào tác vụ Ant) ... Nhưng bạn ơi, 12 quy tắc này cần được cập nhật: bạn có sử dụng kiểm soát nguồn không? Tôi muốn có không hơn CVS, ví dụ; ) (chỉ nửa đùa nửa thật;)
Cedric Martin

7

Tại điểm nào là hữu ích?

  • Chu kỳ xây dựng + kiểm tra của bạn sẽ vượt qua vài phút. Với 5 phút chạy thử, bạn sẽ không còn muốn tự mình chạy tất cả các bài kiểm tra, đặc biệt là đối với những thay đổi nhỏ.
  • Bạn bắt đầu xây dựng nhiều biến thể. Nếu bạn có một vài khách hàng với các tùy chỉnh khác nhau, bạn nên chạy thử nghiệm đối với từng biến thể, vì vậy số lượng công việc sẽ bắt đầu tăng khá nhanh. Hơn bạn chạy bộ thử nghiệm cho một biến thể trên máy của nhà phát triển và để nó cho CI chạy phần còn lại.
  • Bạn viết các bài kiểm tra tích hợp tự động cần một số thiết lập môi trường kiểm tra không tầm thường. Hơn bạn muốn kiểm tra đối với một môi trường kiểm tra chính tắc, vì các nhà phát triển có thể đã sửa đổi môi trường của họ theo nhiều cách khác nhau do những thay đổi phát triển. CI là nơi thích hợp nhất cho môi trường kinh điển.
  • Người kiểm tra chỉ có thể kéo bản dựng mới nhất từ ​​CI. Do đó, họ không cần phải có, tìm hiểu và sử dụng các công cụ phát triển cũng như không có nhà phát triển nào phải gửi cho họ bản dựng của họ theo cách thủ công.
  • Khi bạn đang chuẩn bị phát hành:
    • Kiểm tra trở nên quan trọng hơn, do đó, có một nơi với các bản dựng được chuẩn bị để kiểm tra thậm chí còn hữu ích hơn.
    • Bạn chắc chắn rằng tất cả các bản dựng được xây dựng với cùng một môi trường xây dựng, vì vậy bạn tránh các vấn đề có thể được đưa ra bởi sự khác biệt tinh tế giữa các bản cài đặt của nhà phát triển.
    • Bạn chắc chắn rằng bạn đang xây dựng chính xác những gì được kiểm tra trong hệ thống kiểm soát phiên bản. Trong quá trình phát triển nếu ai đó quên kiểm tra thứ gì đó, bạn sẽ tìm thấy khá nhanh, vì nó sẽ thất bại cho nhà phát triển tiếp theo. Nhưng nếu bản dựng như vậy trượt sang QA hoặc sản xuất và họ báo cáo lỗi, sẽ rất khó để theo dõi.

Có thể bạn chưa cần CI, nhưng tôi nghĩ nó sẽ trở nên hữu ích khi bạn đến giai đoạn thử nghiệm. Jenkins được thiết lập trong vài giờ và nó sẽ đơn giản hóa việc thử nghiệm của bạn và giúp tránh những sai lầm ngớ ngẩn (điều đó xảy ra đặc biệt là khi bạn vội vàng khắc phục nhanh việc sản xuất).


+1, cảm ơn. Nhưng đối số bản dựng tôi không bao giờ thực sự hiểu được: không phải ứng dụng mạnh mẽ hơn khi tất cả các nhà phát triển có thể kiểm tra bất kỳ bản sửa đổi nào và xây dựng cùng một bản dựng, mỗi bản trên máy của họ? Không phải chúng ta chỉ chuyển vấn đề "các bản dựng gắn liền với tài khoản của nhà phát triển" sang "bản dựng gắn liền với máy chủ CI" sao? Ý tôi là: bản thân máy chủ CI có thể bị cấu hình sai và bản dựng do đó trở nên phụ thuộc vào sự khác biệt tinh tế trong quá trình cài đặt của máy chủ CI!? Điều đó nói rằng tôi hơi nhận ra nó có thể hữu ích: Tôi nghĩ rằng tôi chỉ cần "cài đặt và xem" :)
Cedric Martin

@CedricMartin: Máy chủ CI chỉ là một, vì vậy bạn sẽ không gặp phải lỗi do sự khác biệt giữa các môi trường bạn đã thực hiện và xây dựng trước đó và vì bạn không làm việc khác trên máy chủ CI, nên ít có khả năng bạn phá vỡ nó .
Jan Hudec

@CedricMartin: Rõ ràng nếu máy chủ CI được cấu hình sai, bạn sẽ nhận thấy rằng các bản dựng hoạt động khác với các bản dựng được thực hiện trên các hộp của nhà phát triển, vì các nhà phát triển sẽ luôn tự biên dịch. Dễ dàng hơn so với khi một số hộp nhà phát triển cụ thể được cấu hình sai, vì nhiều người có thể nhận thấy.
Jan Hudec

6

Đối với tôi một CI trở nên thú vị nếu nhóm của bạn có nhiều hơn 1 thành viên.

Bạn phải ngừng nghĩ về CI là "một PC khác đang chạy thử nghiệm cho tôi". CI về việc có một quy trình xây dựng được xác định và tự động và quản lý phát hành.

CI là thực thể có thẩm quyền duy nhất tạo ra bản phát hành phần mềm của bạn. Nếu nó không được xây dựng trên CI thì điều đó đã không xảy ra.

Với CI, bạn có các hạn chế để tự động hóa mọi thứ sẽ hiển thị cho bạn tất cả các chỉnh sửa, hack và phím tắt thủ công mà bạn có tại chỗ và chỉ không làm việc với CI và nên tránh ngay từ đầu.

Vấn đề nó tránh được:

  • Ai chịu trách nhiệm xây dựng bản phát hành
  • Người này có sẵn 24/7 không
  • Nhưng nó dựa trên hội chứng máy của tôi
  • Xóa bỏ mọi sự mơ hồ về phiên bản chúng tôi đã phát hành

Ưu điểm (chỉ là quá nhiều để đề cập đến tất cả):

  • Đánh số phiên bản tự động
  • Tích hợp theo dõi vấn đề
  • Tạo số liệu tự động
  • Phân tích mã tĩnh
  • Triển khai tự động
  • Thiết lập nhiều giai đoạn

5

Có một vấn đề cơ bản về Tích hợp liên tục (CI) được nhân đôi hoàn toàn trong câu hỏi của bạn: Thực tiễn CI khó thực hiện và bảo vệ vì phần mềm máy chủ CI không tầm thường để thiết lập, cũng không tầm thường để đưa các dự án của bạn lên và chạy qua CI người phục vụ. Với điều này, thật khó để thấy được lợi ích của việc nắm lấy CI ở đâu.

Trước hết, CI là về cái nhìn sâu sắc và chất lượng. Good CI mang bạn đến gần hơn với dự án của bạn, cung cấp cho bạn thông tin phản hồi phù hợp về số liệu chất lượng, tài liệu, tuân thủ tiêu chuẩn mã hóa, v.v. Nó sẽ cung cấp cho bạn các công cụ để dễ dàng hình dung tất cả những điều này, và cho phép bạn nhanh chóng nhận ra và dễ dàng liên kết một tập hợp các thay đổi với một ảnh chụp nhanh cụ thể của tất cả các số liệu dự án này.

không chỉ là về việc chạy thử nghiệm đơn vị. Không có gì! Điều này mang lại cho tôi chất lượng. CI chấp nhận lỗi, nó không tránh được hoặc vứt chúng đi. Những gì nó làm chỉ đơn giản là cung cấp cho bạn một công cụ để sửa lỗi sớm, thay vì sau này. Vì vậy, bạn không thực sự cam kết mã đã được thử nghiệm trước đó với máy chủ CI. Mặc dù bạn nên cố gắng cam kết mã sạch và không bị hỏng, nhưng thực tế bạn sử dụng máy chủ CI để tự động chạy trình xây dựng tích hợp thông qua mã của bạn và để nó đánh giá xem mọi thứ có đúng không. Nếu nó có, gọn gàng! Nếu không, không có vấn đề gì - thực tiễn CI tốt nói rằng ưu tiên tiếp theo của bạn chỉ là sửa chữa bất cứ điều gì đã bị hỏng. Mà, trong một máy chủ CI tốt, nên dễ dàng chỉ ra cho bạn.

Khi quy mô nhóm tăng lên, việc tích hợp mã của mọi người tự nhiên trở nên khó khăn hơn. Nhiệm vụ của một máy chủ CI tập trung là kiểm tra tất cả các phần tích hợp và loại bỏ gánh nặng đó khỏi các thành viên của nhóm. Vì vậy, bạn phải có mọi người cam kết sớm (và càng sạch càng tốt) và sau đó theo dõi trạng thái bản dựng (thường có thông báo được hình thành). Và một lần nữa, nếu một cái gì đó bị hỏng do cam kết của một số nhà phát triển, thì ngay lập tức nó trở thành khả năng đáp ứng của anh ta để khắc phục điều đó và khiến những bản dựng tự động đó trở lại trạng thái OK ngay lập tức.

Vì vậy, bạn thấy, theo tôi, mỗi dự án đều được hưởng lợi từ việc được tích hợp liên tục. Vấn đề là, cho đến bây giờ và do sự phức tạp khó hiểu từ mỗi máy chủ CI duy nhất mà tôi biết, mọi người thực sự chống lại các thực hành CI trong các dự án nhỏ hơn / đơn giản hơn. Bởi vì, thôi nào, mọi người có nhiều việc phải làm hơn là dành nhiều ngày để cấu hình một phần mềm cồng kềnh, quá phức tạp, kém chất lượng.

Tôi đã có cùng một vấn đề, và đó là điều khiến tôi phát triển Cintient trong thời gian rảnh kể từ khoảng một năm trước. Tiền đề của tôi là làm cho nó đơn giản để cài đặt, định cấu hình và sử dụng, và làm cho nó cung cấp trên các số liệu chất lượng mà mọi người khác đều thất bại hoặc kém hơn. Vì vậy, sau câu trả lời dài này xuất hiện đầu cắm không biết xấu hổ của tôi khi chỉ ra liên kết GitHub cho dự án (miễn phí và mã nguồn mở, natch). Nó cũng có một số ảnh chụp màn hình đẹp, rõ ràng. :-) https://github.com/matamouros/cintient

Hy vọng tôi đã giúp bạn.

(LƯU Ý: Được chỉnh sửa sau bình luận của Bryan Oakley, trên thực tế là tôi nên dành nhiều thời gian hơn để xây dựng một câu trả lời tốt hơn. Tôi cũng nghĩ rằng anh ấy đã đúng.)


Tôi đã bỏ phiếu vì điều này không trả lời câu hỏi, nó chỉ là một quảng cáo. Bạn không bao giờ giải quyết phần nào khi câu hỏi khác hơn là ngầm hiểu "bây giờ, với công cụ của tôi".
Bryan Oakley

Tôi đã dành chút thời gian để chỉnh sửa câu trả lời, theo đề xuất của @ bryan-sồiley.
matamouros

@matamouros: công việc tốt về chỉnh sửa.
Bryan Oakley
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.