Tại sao tôi nên sử dụng MSBuild thay vì các tệp Visual Studio Solution?

Chúng tôi đang sử dụng TeamCity để tích hợp liên tục và nó đang xây dựng các bản phát hành của chúng tôi thông qua tệp giải pháp (.sln). Trước đây tôi đã sử dụng Makefiles cho các hệ thống khác nhau nhưng chưa bao giờ msbuild (mà tôi đã nghe nói là giống như Makefiles + XML mashup). Tôi đã thấy nhiều bài viết về cách sử dụng msbuild trực tiếp thay vì các tệp giải pháp nhưng tôi không thấy câu trả lời rất rõ ràng về lý do tại sao phải làm điều đó.

Vậy, tại sao chúng ta phải bận tâm di chuyển từ các tệp giải pháp sang MSBuild 'makefile'? Chúng tôi có một vài bản phát hành khác nhau bởi một #define (bản dựng kỳ công) nhưng đối với hầu hết mọi thứ đều hoạt động.

Mối quan tâm lớn hơn là bây giờ chúng tôi phải duy trì hai hệ thống khi thêm dự án / mã nguồn.

CẬP NHẬT:

Mọi người có thể làm sáng tỏ vòng đời và tương tác của ba thành phần sau đây không?

1. Tập tin Visual Studio .sln
2. Nhiều tệp .csproj cấp dự án (mà tôi hiểu một tập lệnh msbuild "phụ")
3. Kịch bản msbuild tùy chỉnh

Có an toàn không khi nói rằng .sln và .csproj được sử dụng / duy trì như bình thường từ trong GUI Visual Studio IDE trong khi tập lệnh msbuild tùy chỉnh được viết bằng tay và thường sử dụng .csproj "as-is" hiện có? Đó là một cách tôi có thể thấy giảm sự trùng lặp / trùng lặp trong bảo trì ...

Sẽ đánh giá cao điều này từ kinh nghiệm hoạt động của những người khác

Điểm đầu tiên của thực tế là tệp giải pháp khá kỳ diệu trở thành tệp MSBuild khi MSBuild thực thi nó - đó là điều xảy ra khi bạn xây dựng giải pháp trong phòng thu trực quan. Ngoài ra, tất cả các tệp dự án đó chỉ là các tệp msbuild được quản lý bởi visual studio. Trong thực tế, các tệp dự án xử lý hầu hết các công việc bẩn thực sự ở đây bất kể bạn đang xây dựng từ các giải pháp hoặc xây dựng từ một kịch bản msbuild tùy chỉnh.

Chúng tôi cũng sử dụng TeamCity để xây dựng và xuất bản các ứng dụng và chúng tôi thường sẽ kết thúc với các tập lệnh msbuild tùy chỉnh cho hầu hết các dự án. Vai trò của các tập lệnh này - không thực sự dễ dàng với tệp giải pháp - là đóng gói dự án để triển khai hoặc phân phối. Thông thường các tập lệnh này xử lý một số khía cạnh hoạt động hơn của mọi thứ - như xây dựng dự án web vào một thư mục cụ thể hoặc sao chép trong các cấu hình đang chạy trái ngược với các cấu hình phát triển. Việc nâng vật nặng có xu hướng được xử lý trong chính các tệp dự án - tập lệnh xây dựng chỉ tham chiếu đến các tệp đó, chúng tôi không thử và tạo lại bánh xe đó. Nhìn chung, nó hoạt động rất tốt và nó không thực sự nhiều mã trùng lặp.

Makefile cho msbuild là tệp .sln (hoặc tệp vcproj).

Một dòng lệnh msbuild điển hình sẽ là một cái gì đó như:

msbuild /p:Configuration=Release BigProject.sln

Điểm của việc sử dụng msbuild là để bạn có thể viết kịch bản và tự động hóa quá trình xây dựng. Cho dù bạn có biết hay không, TeamCity vẫn đang sử dụng msbuild.

Hãy để tôi đưa ra câu hỏi của tôi về câu hỏi này.

Mặc dù bạn chắc chắn có thể chỉ cần sử dụng tệp .SLN của mình làm 'quy trình xây dựng', nhưng chính tệp đó thực sự không tạo thành quy trình xây dựng. Tệp Giải pháp thực sự chỉ là một phần của Visual Studio và được sử dụng để phát triển. Nhưng Visual Studio chỉ là một phần của quá trình xây dựng và phát hành. Bạn không thể dựa vào Giải pháp để quản lý bản dựng của mình và Giải pháp chắc chắn không cung cấp tình huống xây dựng có thể mở rộng.

Toàn bộ mục đích của việc thiết lập quy trình xây dựng là tạo ra các bản dựng đáng tin cậy. Điều đó có nghĩa là, quá trình xây dựng đáng tin cậy đến mức cho dù cấu hình bản dựng là gì, bạn sẽ nhận được một đầu ra bản dựng có thể dự đoán được. Mọi lúc, mọi máy. Kết quả của một bản dựng có thể dự đoán và đáng tin cậy là quá trình thử nghiệm, triển khai và phát hành sau đó có thể được tự động hóa cao, tiếp tục giảm nguy cơ lỗi của con người.

Thiết lập quy trình xây dựng đòi hỏi phải đầu tư, nhưng trong một số trường hợp nhất định, đầu tư là bắt buộc. Dưới đây là một số yếu tố ủng hộ quá trình msbuild:

• Sản phẩm của bạn có nhiều nhóm (đa chức năng hoặc cách khác) đang làm việc trong cùng một dự án nhóm
• Tổ chức của bạn chỉ có một dự án nhóm (nên là trường hợp của 99% cửa hàng truyền thống, ngay cả những cửa hàng có hơn 200 nhà phát triển)
• Bạn có hơn 20 dự án cần được xây dựng, một số dự án có sự phụ thuộc vào người khác và được duy trì bởi các nhóm khác nhau
• Sản phẩm của bạn kết hợp nhiều công nghệ .NET (C #, C ++, VB, F #, ASP.NET, v.v.) hoặc thậm chí các công nghệ không phải .NET (Grunt, nút, npm, Java, v.v.)
• Sản phẩm của bạn có các phụ thuộc nặng hoặc được xây dựng trên nền tảng hạng nặng. SharePoint, làm ví dụ

Hãy để tôi đưa ra một ví dụ để mở rộng về điểm cuối cùng của tôi. Công ty hiện tại của tôi không phát triển SharePoint. Phát triển SharePoint ở mức tối thiểu yêu cầu nền tảng SharePoint phải được cài đặt để thực hiện các bản dựng trên các dự án SharePoint. Nói về một máy chủ xây dựng nhẹ, việc yêu cầu máy chủ xây dựng phải cài đặt SharePoint là hoàn toàn không thực tế. SharePoint không chỉ là một con thú có yêu cầu cao mà nó còn có ý nghĩa hiệu suất nghiêm trọng đối với bản dựng - và các bản dựng được cho là nhanh và gọn nhất có thể. Tận dụng MSBuild cho phép tôi loại bỏ yêu cầu cài đặt này trên máy chủ xây dựng. Trong thực tế, máy chủ xây dựng của chúng tôi không có yêu cầu cài đặt nào ngoài .NET framework (được yêu cầu bởi MSBuild) và Node.

Để tham khảo, tôi khuyên bạn nên xem cuốn sách này của Sayed Ibrahim Hashimi: http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1?ie=UTF8&qid=14120150 8-1-fkmr0 & Keywords = msbuild + đáng tin cậy + xây dựng

Đây chính xác là câu hỏi tôi đã tự hỏi mình vài tháng trước! Chúng tôi đã thiết lập mọi thứ độc đáo:

• Tập tin giải pháp độc đáo trong thư mục gốc của kho
• Xây dựng các bước được định cấu hình trong Teamcity, như
  • Khôi phục các gói NuGet
  • Xây dựng giải pháp
  • Chạy thử nghiệm đơn vị
  • Thiết lập môi trường kiểm tra tích hợp
  • Chạy thử nghiệm tích hợp
  • Xé môi trường kiểm tra tích hợp
  • Tạo gói triển khai
  • Xây dựng tập lệnh di chuyển

Và sau đó, khi nói đến khả năng tái tạo, rõ ràng là điều này đạt điểm thấp. Khi bạn để TeamCity là tập lệnh xây dựng của mình, sẽ rất khó để tạo lại kết quả tương tự, đáng tin cậy, trên máy phát triển của riêng bạn.

Khi bạn có một tập lệnh xây dựng, tập lệnh xây dựng sẽ biết mọi thứ cần được thực hiện và có tất cả các biến. Khi bạn sử dụng máy chủ CI làm tập lệnh xây dựng của mình và một số sự cố xảy ra, như thử nghiệm phức tạp không thành công hoặc cần xây dựng gói triển khai theo cách thủ công (theo ví dụ của tôi), bạn cần ghép tất cả các bước của quá trình xây dựng với nhau theo cách thủ công.

Vì vậy, trong ngắn hạn , tại sao một (MS) xây dựng kịch bản? Bởi vì bạn sẽ có nhiều yêu cầu hơn khi nói đến bản dựng của bạn. Bạn có thể muốn chạy một số thử nghiệm và tạo ra một số tạo tác từ đó. Bạn có thể muốn thực hiện triển khai. Và khi mọi thứ bạn muốn cần có thể chạy được, cho dù đó là trên máy chủ xây dựng hay máy của bạn, nó không thể kết thúc ở bất cứ đâu ngoài tập lệnh xây dựng.