2010-05-19 28 views
16

Nhóm .NET của chúng tôi hoạt động trên các dự án cho công ty của chúng tôi thuộc các danh mục riêng biệt. Một số là ứng dụng web nội bộ, một số là ứng dụng web bên ngoài (công khai), chúng tôi cũng có các ứng dụng Windows nội bộ cho người dùng văn phòng công ty và ứng dụng Windows Forms cho các cửa hàng bán lẻ (cửa hàng) của chúng tôi. Tất nhiên, bởi vì chúng tôi ghét sử dụng lại mã, chúng tôi có một tấn mã được chia sẻ giữa các ứng dụng khác nhau. Hiện nay chúng tôi đang sử dụng SVN như kiểm soát nguồn của chúng tôi, và chúng tôi đã có kho lưu trữ của chúng tôi đặt ra như thế này:TFS và các dự án được chia sẻ trong nhiều giải pháp

- = folder, | = Visual Studio Solution 
-SVN 
    - Internet 
     | Ourcompany.com 
     | Oursecondcompany.com 
    - Intranet 
     | UniformOrdering website 
     | MessageCenter website 
    - Shared 
     | ErrorLoggingModule 
     | RegularExpressionGenerator 
     | Anti-Xss 
     | OrgChartModule etc... 

Vì vậy ..

Giải pháp OurCompany.com trong thư mục Internet sẽ có một trang web dự án, và nó cũng sẽ bao gồm các dự án ErrorLoggingModule, RegularExpressionGenerator và Anti-Xss từ thư mục được chia sẻ.

Tương tự, giải pháp trang web UniformOrdering của chúng tôi cũng sẽ có từng dự án trong giải pháp này.

Chúng tôi muốn có một tham chiếu dự án đến một tài liệu tham khảo .dll vì trước tiên, nếu chúng ta cần thêm hoặc sửa một hàm trong ErrorLoggingModule trong khi làm việc trên trang web OurCompany.com, nó ở ngay đó. Ngoài ra, điều này cho phép chúng tôi xây dựng từng giải pháp và xem liệu các thay đổi đối với mã chia sẻ có phá vỡ bất kỳ ứng dụng nào khác không. Điều này cũng sẽ hoạt động tốt trên máy chủ xây dựng nếu tôi chính xác.

Trong SVN, không có vấn đề gì với điều này. SVN và Visual Studio không gắn kết với nhau trong cách kiểm soát nguồn của TFS. Chúng tôi không bao giờ tìm ra cách làm việc kiểu cấu trúc này trong TFS khi chúng ta đang sử dụng nó, bởi vì trong TFS, dự án TFS luôn gắn liền với một giải pháp Visual Studio. Kho lưu trữ mã nguồn là một phần tử con của dự án TFS, vì vậy nếu chúng ta muốn làm điều này, chúng ta phải lặp lại mã được chia sẻ trong mỗi kho lưu trữ mã nguồn của dự án TFS. Khi đồng nghiệp của tôi đặt nó, điều này "phá vỡ mọi thực hành tốt nhất được biết về tái sử dụng mã và đơn giản". Đó là đủ của một máy cắt giao dịch cho chúng tôi rằng chúng tôi chuyển sang SVN. Tuy nhiên, bây giờ, chúng tôi đang phải đối mặt với việc thực sự sửa chữa các quy trình phát triển của chúng tôi và Quản lý vòng đời ứng dụng của TFS khá gần với chính xác những gì chúng tôi muốn và cách chúng tôi muốn làm việc. Điểm gắn bó của chúng tôi là vấn đề mã được chia sẻ.

Chúng tôi đang đánh giá các giải pháp thương mại và mã nguồn mở khác, nhưng vì chúng tôi đã thanh toán cho TFS bằng Đăng ký MSDN của chúng tôi và TFS chính xác là những gì chúng tôi muốn, chúng tôi thực sự muốn tìm cách vấn đề.

Có ai khác phải đối mặt với điều này và đưa ra giải pháp không?

Nếu bạn đã xem một bài viết hoặc đăng bài trên trang này mà bạn có thể chia sẻ với tôi, điều đó cũng sẽ hữu ích.

Như mọi khi, tôi mở cửa cho câu trả lời như "Bạn đang nhìn vào nó hoàn toàn sai, Bonehead, đây là cách thức mà nó nên được thực hiện.

Trả lời

15

Tôi nghĩ rằng có một số hiểu lầm ở đây. Thứ nhất, bạn có thể có nhiều giải pháp (nhiều như bạn muốn) trong một dự án TFS đơn lẻ, ngoài ra, một dự án Visual Studio đơn lẻ có thể có bất kỳ số lượng giải pháp nào đề cập đến nó. 2005/08 trong cách xử lý các dự án TFS

Dưới năm 2008, có một số cách để tiếp cận điều này tùy thuộc vào những gì bạn muốn thoát ra khỏi nó. Bạn có thể có nhiều dự án TFS hoặc một dự án TFS đơn lẻ.

Tôi sẽ bắt đầu bằng nhiều.

Thiết lập dự án TFS cho mã loại thư viện được chia sẻ của bạn và các dự án khác cho từng dự án thông thường mà bạn có. Là một phần của quá trình phát triển trên thư viện được chia sẻ này, hãy kiểm tra trong các hội đồng đã hoàn thành. Sau đó, Branch các assembly đó vào bất kỳ dự án TFS nào khác mà bạn muốn sử dụng chúng. Khi bạn cập nhật tính năng hoặc sửa lỗi cho thư viện chia sẻ, chỉ cần hợp nhất nhánh vào bất kỳ dự án TFS nào khác mà bạn muốn cập nhật.

Điều này cho phép bạn thực hiện các thay đổi được chia sẻ cho một ứng dụng mà không cần phải đẩy tất cả chúng.

Nếu bạn muốn một dự án TFS duy nhất giữ mọi thứ, chỉ cần thêm thư mục cho từng dự án Visual Studio mà bạn muốn. Các giải pháp studio trực quan có thể tham khảo lại các dự án bên ngoài cây cơ sở của họ mà không gặp vấn đề gì. Bây giờ, khi định cấu hình những thứ như Xây dựng cho từng giải pháp, hãy đảm bảo bạn giới hạn thư mục mà máy chủ xây dựng kéo từ/đồng hồ. Bằng cách đó bạn không có nó xây dựng một trong các trang web nội bộ của bạn khi thay đổi được thực hiện cho một trang web bên ngoài.

+0

Cảm ơn bạn đã dành thời gian đọc câu trả lời này. Khi chúng tôi gặp vấn đề ban đầu, chúng tôi đã sử dụng phiên bản 2005. Bạn có thể chỉ cho tôi, bằng bất kỳ cơ hội nào, tài liệu về cách VS2010 khác với năm 2005/2008 không? Chúng tôi sẽ sử dụng năm 2010 nếu chúng tôi chuyển về TFS. Tôi sẽ thiết lập môi trường ảo và thử hai phương pháp bạn đã đề cập. Có vẻ tốt, vì vậy +1 và nếu chúng tôi sử dụng nó (hoặc nếu tôi không nhận được câu trả lời nào tốt hơn), tôi cũng sẽ chấp nhận câu trả lời của bạn. – David

+0

2010 có cách tiếp cận khác với các dự án nhóm. Họ có một điều mới gọi là "Bộ sưu tập dự án" mà sẽ chính xác những gì bạn muốn. Thông tin có tại đây: http://msdn.microsoft.com/en-us/library/dd236915.aspx – NotMe

+0

Một lần nữa, cảm ơn bạn. Xin lỗi đã mất quá nhiều thời gian, nhưng tôi mất một lúc để thiết lập môi trường của mình. Tôi chấp nhận câu trả lời của bạn chủ yếu dựa trên lưu ý cuối cùng này vì nó chính xác là những gì tôi muốn, nhưng câu trả lời ban đầu của bạn cũng tốt. Tôi biết ơn thời gian bạn đã bỏ ra. – David

4

Chỉ ghi lại điều này với hy vọng rằng nó giúp người khác một ngày nào đó, tôi lo là tôi đã quá trễ để trả lời câu hỏi gốc của bạn;) Chúng tôi có một tình huống rất giống nhau và câu hỏi của bạn (và các câu trả lời tiếp theo) giúp chúng tôi dễ dàng thiết lập TFS đúng cách.

Để sử dụng ví dụ của bạn để giải thích thiết lập của chúng tôi:

# = Project Collection, > = Team Project, | = VS project 
# SVN 
    > Internet 
     | OurCompany 
     | OurCompany2 
    > Intranet 
     | UniformOrdering 
     | MessageCentre 
    > Shared 
     | ErrorLogging 
     | RegularExpression 

Điều này có nghĩa rằng công việc có thể được gán (sử dụng Scrum mẫu trong Sharepoint) với bất kỳ dự án Team (mà những ứng dụng SAAS trong trường hợp của chúng tôi) và nhà phát triển có thể chọn mở bất kỳ hoặc tất cả các dự án VS để hoàn thành công việc.

Phần lớn các nhà phát triển cao cấp (có nhiều sản phẩm) có một giải pháp VS (có thể là "WholeEnterprise.sln" để tiếp tục tương tự) có chứa TẤT CẢ các dự án VS khác nhau và do đó có thể làm việc trên bất kỳ/tất cả chúng bất cứ lúc nào. Chúng tôi cũng có thể đảm bảo rằng các dự án xây dựng đúng cách và tất cả các phụ thuộc đều được cập nhật trước khi đẩy cập nhật.

Cấu trúc của điều này trong hệ điều hành bạn chọn hoàn toàn tùy thuộc vào bạn! Một số người trong chúng ta đã nhân rộng cấu trúc của TFS, những người khác có một hệ thống phân cấp hoàn toàn bằng phẳng ... Điều này dường như không tạo nên sự khác biệt vào cuối ngày.

+0

Và đó chính xác là cấu trúc tương tự chúng tôi đã chọn. +1 và cảm ơn bạn đã chia sẻ. – David

+0

Tôi muốn chỉ ra ah-ha lớn! thời điểm đối với tôi là nhận ra rằng bạn không kiểm tra các giải pháp cho TFS, bạn chỉ kiểm tra các dự án. – stricq

+3

nếu bạn không kiểm tra giải pháp, tệp .sln thực sự được sao lưu ở đâu? Đối với tôi đó là một trong những mục tiêu chính của điều khiển phiên bản: Có tất cả các tệp được sao lưu và được phiên bản. – Mat

Các vấn đề liên quan