Làm thế nào và tại sao tôi thiết lập máy xây dựng C #? [đóng cửa]

Tôi đang làm việc với một nhóm phát triển nhỏ (4 người) trong một dự án C #. Tôi đã đề xuất thiết lập một cỗ máy xây dựng sẽ thực hiện các bản dựng và kiểm tra hàng đêm của dự án, bởi vì tôi hiểu rằng đây là một điều tốt. Rắc rối là, chúng tôi không có nhiều ngân sách ở đây, vì vậy tôi phải chứng minh chi phí cho các quyền lực. Vì vậy tôi muốn biết:

Cập nhật: Jenkins là phiên bản cập nhật nhất của Hudson. Mọi người nên sử dụng Jenkins ngay bây giờ. Tôi sẽ cập nhật các liên kết tương ứng.

Hudson là miễn phí và cực kỳ dễ cấu hình và sẽ dễ dàng chạy trên máy ảo.

Một phần từ một bài viết cũ của tôi:

Chúng tôi sử dụng nó để

• Triển khai các dịch vụ Windows
• Triển khai các dịch vụ web
• Chạy MSTests và hiển thị nhiều thông tin như bất kỳ bài kiểm tra nào
• Theo dõi các nhiệm vụ thấp, med, cao
• cảnh báo xu hướng và lỗi

Dưới đây là một số nội dung .net tích hợp mà Hudson hỗ trợ

• MSBuild
• NAnt
• MSTest
• Nữ tu
• Nhóm máy chủ nền tảng
• ống kính
• bút stylus
• cảnh báo trình biên dịch
• nhiệm vụ mã

Ngoài ra, chúa cấm bạn đang sử dụng nguồn hình ảnh an toàn, nó cũng hỗ trợ điều đó . Tôi khuyên bạn nên xem bài viết của Redsolo về việc xây dựng các dự án .net bằng Hudson

Những câu hỏi của bạn

• Q : Tôi cần loại công cụ / giấy phép nào? Ngay bây giờ, chúng tôi sử dụng Visual Studio và Smart hội để xây dựng và Perforce để kiểm soát nguồn. Tôi sẽ cần một cái gì đó khác, hoặc có một công việc tương đương để chạy các kịch bản tự động không?

• Trả lời: Tôi vừa cài đặt studio hình ảnh trên một bản sao mới của VM đang chạy bản cài đặt mới, được vá, của hệ điều hành máy chủ windows. Vì vậy, bạn cần giấy phép để xử lý đó. Hudson sẽ tự cài đặt như một dịch vụ windows và chạy trên cổng 8080 và bạn sẽ định cấu hình tần suất bạn muốn nó quét kho lưu trữ mã của bạn để tìm mã cập nhật hoặc bạn có thể yêu cầu nó xây dựng vào một thời điểm nhất định. Tất cả cấu hình thông qua trình duyệt.

• Q: Chính xác thì điều này sẽ giúp tôi, ngoài một dấu hiệu của một bản dựng bị hỏng? Tôi có nên thiết lập các dự án thử nghiệm trong giải pháp này (tệp sln) sẽ được chạy bởi các tập lệnh này, để tôi có thể kiểm tra các chức năng cụ thể không? Hiện tại, chúng tôi có hai bài kiểm tra như vậy, bởi vì chúng tôi chưa có thời gian (hay nói thẳng ra là kinh nghiệm) để thực hiện các bài kiểm tra đơn vị tốt.

  Trả lời: Bạn sẽ nhận được email vào lần đầu tiên xây dựng thất bại hoặc không ổn định. Bản dựng không ổn định nếu kiểm tra đơn vị thất bại hoặc có thể được đánh dấu là không ổn định thông qua bất kỳ số tiêu chí nào bạn đặt. Khi kiểm tra đơn vị hoặc xây dựng thất bại, bạn sẽ được gửi qua email và nó sẽ cho bạn biết nơi nào, tại sao và làm thế nào nó thất bại. Với cấu hình của tôi, chúng tôi nhận được:

  • danh sách tất cả các cam kết kể từ lần xây dựng cuối cùng
  • cam kết ghi chú của những cam kết
  • danh sách các tập tin thay đổi trong các cam kết
  • đầu ra giao diện điều khiển từ bản dựng, hiển thị lỗi hoặc lỗi kiểm tra

• Q: Tôi cần loại phần cứng nào cho việc này?

  A: Một VM sẽ đủ

• Q: Một khi bản dựng đã được hoàn thành và thử nghiệm, đó có phải là một cách phổ biến để đặt bản dựng đó lên một trang web ftp hoặc có một số cách khác để truy cập nội bộ? Ý tưởng là cỗ máy này tạo ra bản dựng, và tất cả chúng ta đều đi đến nó, nhưng có thể tạo bản dựng gỡ lỗi nếu chúng ta phải.

  Trả lời: Hudson có thể làm bất cứ điều gì bạn muốn với nó, bao gồm cả ID thông qua hàm băm md5, tải lên, sao chép nó, lưu trữ nó, v.v. Nó tự động thực hiện và cung cấp cho bạn một lịch sử xây dựng lâu dài.

• Q: Bao lâu thì chúng ta nên thực hiện kiểu xây dựng này?

  Trả lời: Chúng tôi có cuộc thăm dò ý kiến ​​SVN mỗi giờ, tìm kiếm các thay đổi mã, sau đó chạy một bản dựng. Nightly là ok, nhưng IMO hơi vô giá trị vì những gì bạn đã làm việc ngày hôm qua sẽ không còn mới mẻ trong tâm trí bạn vào buổi sáng khi bạn bước vào.

• Q: Không gian được quản lý như thế nào? Nếu chúng ta thực hiện các bản dựng hàng đêm, chúng ta có nên giữ xung quanh tất cả các bản dựng cũ hay bắt đầu bỏ chúng sau khoảng một tuần hay không?

  Trả lời: Điều đó tùy thuộc vào bạn, sau một thời gian dài, tôi chuyển các tạo phẩm xây dựng của chúng tôi sang lưu trữ dài hạn hoặc xóa chúng, nhưng tất cả dữ liệu được lưu trữ trong tệp văn bản / tệp xml tôi giữ, điều này cho phép tôi lưu trữ thay đổi, biểu đồ xu hướng, vv trên máy chủ với không gian tiêu thụ ít verrrry. Ngoài ra, bạn có thể thiết lập Hudson để chỉ giữ các vật phẩm từ một số bản dựng

• Q: Có gì khác tôi không thấy ở đây?

  A: Không, hãy đến Hudson ngay bây giờ, bạn sẽ không thất vọng đâu!

Chúng tôi đã có may mắn lớn với combo sau:

1. Visual Studio (cụ thể là sử dụng công cụ dòng lệnh MSBuild.exe và truyền cho nó các tệp giải pháp của chúng tôi. Loại bỏ sự cần thiết của các tập lệnh msbuild)
2. NAnt (như thư viện tác vụ / cú pháp XML tốt hơn MSBuild. Cũng có các tùy chọn cho các hoạt động kiểm soát src P4)
3. CruiseControl.net - được xây dựng trong bảng điều khiển web để theo dõi / bắt đầu xây dựng.

CCNet đã tích hợp sẵn các thông báo để gửi email khi quá trình xây dựng thành công / thất bại

Về biện minh: Điều này sẽ giảm tải cho các nhà phát triển thực hiện các bản dựng thủ công và thực hiện rất nhiều lỗi của con người khỏi phương trình. Rất khó để định lượng hiệu ứng này, nhưng một khi bạn làm điều đó, bạn sẽ không bao giờ quay trở lại. Có một quy trình lặp lại để xây dựng và phát hành phần mềm là điều tối quan trọng. Tôi chắc chắn rằng bạn đã từng là nơi họ xây dựng phần mềm bằng tay và nó được đưa ra ngoài tự nhiên, chỉ để anh chàng xây dựng của bạn nói "Rất tiếc, tôi đã quên không bao gồm DLL mới đó!"

Về phần cứng: mạnh mẽ như bạn có thể nhận được. Nhiều năng lượng / bộ nhớ = thời gian xây dựng nhanh hơn. Nếu bạn có đủ khả năng thì bạn sẽ không bao giờ hối tiếc khi có được một cỗ máy xây dựng hàng đầu, bất kể nhóm nhỏ như thế nào.

Về không gian: Giúp có nhiều dung lượng đĩa cứng. Bạn có thể tạo các tập lệnh NAnt của mình để xóa các tệp trung gian mỗi khi quá trình xây dựng bắt đầu, vì vậy vấn đề thực sự là giữ lịch sử nhật ký và trình cài đặt ứng dụng cũ. Chúng tôi có phần mềm theo dõi không gian đĩa và gửi thông báo. Sau đó, chúng tôi dọn sạch ổ đĩa bằng tay. Thường cần phải được thực hiện mỗi 3-4 tháng.

Về thông báo xây dựng: Điều này được tích hợp sẵn trong CCNet, nhưng nếu bạn định thêm kiểm tra tự động như một bước bổ sung thì hãy xây dựng dự án này vào dự án ngay từ đầu. Rất khó để trở lại các bài kiểm tra phù hợp khi dự án trở nên lớn. Có rất nhiều thông tin về các khung kiểm tra ngoài kia (có thể là cả tấn thông tin về SO), vì vậy tôi sẽ trì hoãn việc đặt tên cho bất kỳ công cụ cụ thể nào.

Tại nơi làm việc trước đây của chúng tôi, chúng tôi đã sử dụng TeamCity . Nó rất dễ dàng và mạnh mẽ để sử dụng. Nó có thể được sử dụng miễn phí với một số hạn chế. Ngoài ra còn có một hướng dẫn về Dime Casts . Lý do chúng tôi không sử dụng CruiseControl.NET là vì chúng tôi đã có rất nhiều dự án nhỏ và khá khó khăn để thiết lập từng dự án trong CC.NET. Tôi rất muốn giới thiệu TeamCity. Tóm lại, nếu bạn hướng tới nguồn mở thì CC.NET là ông bố lớn với đường cong học tập cao hơn một chút. Nếu ngân sách của bạn cho phép bạn chắc chắn đi với TeamCity hoặc kiểm tra phiên bản miễn phí.

Làm sao? Hãy xem blog của Carel Lotz .

Tại sao? Có một số lý do mà tôi có thể nghĩ ra:

• Bản dựng hoạt động, khi được triển khai đúng cách, có nghĩa là tất cả các nhà phát triển của bạn có thể xây dựng trên máy của họ khi bản dựng có màu xanh
• Bản dựng hoạt động, khi được triển khai đúng cách, có nghĩa là bạn sẵn sàng triển khai bất cứ lúc nào
• Một bản dựng hoạt động, khi được triển khai đúng cách, có nghĩa là bất cứ điều gì bạn phát hành đã thực hiện một chuyến đi đến hệ thống kiểm soát nguồn của bạn.
• Một bản dựng hoạt động, khi được triển khai đúng cách, có nghĩa là bạn tích hợp sớm và thường xuyên, giảm rủi ro tích hợp.

Bài viết của Martin Fowler về Tích hợp liên tục vẫn là văn bản dứt khoát. Có một cái nhìn vào nó!

Lập luận chính có lợi là nó sẽ cắt giảm chi phí cho quá trình phát triển của bạn, bằng cách thông báo cho bạn càng sớm càng tốt rằng bạn có bản dựng bị hỏng hoặc thử nghiệm thất bại.

Vấn đề tích hợp công việc của nhiều nhà phát triển là mối nguy hiểm chính của việc phát triển một nhóm. Nhóm càng lớn, càng khó phối hợp công việc của họ và ngăn chặn họ gây rối với những thay đổi của nhau. Giải pháp tốt duy nhất là bảo họ "hòa nhập sớm và thường xuyên", bằng cách kiểm tra trong các đơn vị công việc nhỏ (đôi khi được gọi là "câu chuyện") khi chúng được hoàn thành.

Bạn nên làm cho máy xây dựng xây dựng lại MỌI thời gian một số kiểm tra trong suốt cả ngày. Với Cruise Control, bạn có thể nhận được một biểu tượng trên thanh tác vụ chuyển sang màu đỏ (và thậm chí nói chuyện với bạn!) Khi bản dựng bị hỏng.

Sau đó, bạn nên thực hiện bản dựng hoàn toàn hàng đêm trong đó phiên bản nguồn được gắn nhãn (được cung cấp số bản dựng duy nhất) mà bạn có thể chọn để xuất bản cho các bên liên quan (người quản lý sản phẩm, người QA). Điều này là để khi một lỗi được báo cáo, nó chống lại số bản dựng đã biết (điều đó cực kỳ quan trọng).

Lý tưởng nhất là bạn nên có một trang web nội bộ nơi có thể tải xuống các bản dựng và có một nút bạn có thể nhấp để xuất bản bản dựng hàng đêm trước đó.

Chỉ cố gắng xây dựng một chút về những gì mjmarsh nói, vì anh ta đã đặt nền tảng tuyệt vời ...

• Visual Studio. MSBuild hoạt động tốt.
• NAnt .
• Nam Kinh . Điều này sẽ cung cấp các nhiệm vụ bổ sung như hoạt động của Perforce.
• CruiseControl.net . Đây là một lần nữa về cơ bản "bảng điều khiển xây dựng" của bạn.

Tất cả những điều trên (tiết kiệm cho VS) là nguồn mở, vì vậy bạn không xem xét bất kỳ giấy phép bổ sung nào.

Như Earwicker đã đề cập, xây dựng sớm, xây dựng thường xuyên. Biết một cái gì đó đã phá vỡ, và bạn có thể sản xuất một sản phẩm có thể giao được là hữu ích để nắm bắt sớm mọi thứ.

NAnt bao gồm các nhiệm vụ cho nunit / nunit2 , vì vậy bạn thực sự có thể tự động hóa thử nghiệm đơn vị của mình. Sau đó, bạn có thể áp dụng biểu định kiểu cho kết quả và với sự trợ giúp của khung được cung cấp bởi CruiseControl.net, có kết quả kiểm tra đơn vị dễ đọc, có thể in được cho mọi bản dựng.

Điều tương tự áp dụng cho nhiệm vụ ndoc . Có tài liệu của bạn được sản xuất và có sẵn, cho mọi bản dựng.

Thậm chí, bạn có thể sử dụng tác vụ exec để thực thi các lệnh khác, ví dụ, tạo Trình cài đặt Windows bằng InstallShield.

Ý tưởng là để tự động hóa việc xây dựng càng nhiều càng tốt, bởi vì con người đã phạm sai lầm. Thời gian dành cho phía trước là thời gian lưu xuống đường. Mọi người không cần phải trông nom việc xây dựng bằng cách trải qua quá trình xây dựng. Xác định tất cả các bước trong bản dựng của bạn, tạo tập lệnh NAnt cho từng tác vụ và xây dựng tập lệnh NAnt của bạn từng cái một cho đến khi bạn hoàn toàn tự động hóa toàn bộ quy trình xây dựng của mình. Sau đó, nó cũng đặt tất cả các bản dựng của bạn ở một nơi, tốt cho mục đích so sánh. Một cái gì đó phá vỡ trong Build 426 hoạt động tốt trong Build 380? Chà, có những sản phẩm đã sẵn sàng để thử nghiệm - lấy chúng và thử đi.

• Không cần giấy phép. CruiseControl.net có sẵn miễn phí và chỉ cần .NET sdk để xây dựng.
• Một máy chủ xây dựng, ngay cả khi không có kiểm tra đơn vị tự động vẫn cung cấp môi trường được kiểm soát để phát hành bản dựng. Không còn nữa "John thường xây dựng trên máy của anh ấy nhưng anh ấy bị ốm. Vì một số lý do tôi không thể xây dựng trên máy của mình"
• Ngay bây giờ tôi có một thiết lập trong phiên PC ảo.
• Đúng. Việc xây dựng cần phải được đổ ở đâu đó có thể truy cập. Xây dựng phát triển nên đã bật gỡ lỗi. Phát hành bản dựng nên đã tắt nó.
• Làm thế nào thường là tùy thuộc vào bạn. Nếu được thiết lập chính xác, bạn có thể xây dựng sau mỗi lần đăng ký sẽ rất ít chi phí. Đây là một ý tưởng tuyệt vời nếu bạn có (hoặc đang có kế hoạch có) các bài kiểm tra đơn vị tại chỗ.
• Giữ các cột mốc và phát hành miễn là cần thiết. Bất cứ điều gì khác phụ thuộc vào mức độ thường xuyên bạn xây dựng: liên tục? vứt đi. Hằng ngày? Giữ giá trị một tuần. Hàng tuần? Giữ giá trị hai tháng.

Dự án của bạn càng lớn thì bạn càng thấy được lợi ích của một máy xây dựng tự động.

Đó là tất cả về sức khỏe của bản dựng. Điều này mang lại cho bạn là bạn có thể thiết lập bất kỳ loại điều bạn muốn xảy ra với các bản dựng. Trong số này bạn có thể chạy thử nghiệm, phân tích tĩnh và hồ sơ. Các vấn đề được giải quyết nhanh hơn nhiều, khi gần đây bạn đã làm việc trên phần đó của ứng dụng. Nếu bạn thực hiện các thay đổi nhỏ, thì nó gần như cho bạn biết bạn đã phá vỡ nó ở đâu :)

Tất nhiên, điều này là giả sử, bạn thiết lập nó để xây dựng với mỗi lần đăng nhập (tích hợp liên tục).

Nó cũng có thể giúp đưa QA và Dev đến gần hơn. Như bạn có thể thiết lập các bài kiểm tra chức năng để chạy với nó, cùng với trình lược tả và mọi thứ khác giúp cải thiện phản hồi cho nhóm nhà phát triển. Điều này không có nghĩa là các kiểm tra chức năng chạy với mỗi lần đăng nhập (có thể mất một chút thời gian), nhưng bạn thiết lập các bản dựng / kiểm tra với các công cụ chung cho cả nhóm. Tôi đã tự động hóa các thử nghiệm khói, vì vậy trong trường hợp của tôi, chúng tôi hợp tác chặt chẽ hơn nữa.

Tại sao: 10 năm trước, chúng tôi với tư cách là nhà phát triển phần mềm đã sử dụng để phân tích thứ gì đó đến mức thứ n, hãy lấy tài liệu (viết bằng ngôn ngữ của con người) 'ký tắt' rồi bắt đầu viết mã. Chúng tôi sẽ kiểm tra đơn vị, kiểm tra chuỗi và sau đó chúng tôi sẽ kiểm tra hệ thống: lần đầu tiên toàn bộ hệ thống sẽ được chạy cùng nhau, đôi khi vài tuần hoặc vài tháng sau khi chúng tôi nhận được các tài liệu. Chỉ sau đó chúng tôi sẽ khám phá tất cả các giả định và hiểu lầm chúng tôi có khi chúng tôi phân tích tất cả mọi thứ.

Tích hợp liên tục và ý tưởng khiến bạn xây dựng một hệ thống hoàn chỉnh (mặc dù, ban đầu, rất đơn giản) để kết thúc. Theo thời gian chức năng hệ thống được xây dựng trực giao. Mỗi khi bạn thực hiện một bản dựng hoàn chỉnh, bạn sẽ thực hiện kiểm tra hệ thống sớm và thường xuyên. Điều này có nghĩa là bạn tìm và sửa các lỗi và giả định càng sớm càng tốt, khi đó là thời gian rẻ nhất để sửa chúng.

Làm thế nào: Về cách thức, tôi đã viết blog về điều này một chút trước đây: [ Bấm vào đây ]

Hơn 8 bài đăng, từng bước hướng dẫn cách thiết lập máy chủ Jenkins trong môi trường windows cho các giải pháp .NET.