Cách tốt nhất: cơ cấu lại giải pháp Team Foundation Server (TFS) hiện có


12

Trong bộ phận của tôi, chúng tôi đang phát triển một số AddOns nhỏ hơn cho một số máy chủ liên lạc hợp nhất. Để tạo phiên bản và phát triển phân tán, chúng tôi sử dụng Team Foundation Server 2012.

Nhưng: chỉ có một giải pháp TFS lớn cho tất cả các ứng dụng và thư viện của chúng tôi:

  • Giải pháp chính
    • Các ứng dụng
      • Ứng dụng 1
      • Ứng dụng 2
      • Ứng dụng 3
    • Bên ngoài
    • Thư viện
      • Thiên Bình 1
      • Thiên 2
    • Công cụ

Đường dẫn "Ứng dụng" chứa tất cả các ứng dụng chính. Chúng không phụ thuộc vào nhau, nhưng chúng phụ thuộc vào các dự án Thư viện và Externals.

Đường dẫn "Externals" chứa một số DLL bên ngoài được tham chiếu trong Ứng dụng và Thư viện của chúng tôi.

Đường dẫn Thư viện chứa các lib thường được sử dụng (các mẫu UI, các lớp Trình trợ giúp, v.v.). Chúng không phụ thuộc vào nhau và chúng được tham chiếu trong các dự án Thư viện và Công cụ.

Đường dẫn Công cụ chứa một số chương trình trợ giúp như trình trợ giúp thiết lập, cập nhật dịch vụ web, v.v.

Bây giờ, có một số điểm chính tại sao tôi muốn thay đổi cấu trúc này:

  • Chúng tôi không thể sử dụng các bản dựng máy chủ.
  • Thật khó chịu khi quản lý quản lý scrum TFS bằng nước rút, chướng ngại vật, v.v ... với cấu trúc giải pháp như thế.
  • Mọi nhà phát triển luôn có quyền truy cập vào tất cả các dự án trong giải pháp.
  • Bản dựng hoàn chỉnh tồn tại quá lâu nếu một người vô tình chạm vào [F6] trong Visual Studio ...

Bạn sẽ thay đổi điều gì trong giải pháp này? Làm thế nào bạn có thể chia các dự án đó thành các Giải pháp nhỏ hơn, các giải pháp đó nên được cấu trúc như thế nào.

Cách tiếp cận đầu tiên của tôi sẽ là, tạo một dự án TFS cho mỗi Ứng dụng, Thư viện và Công cụ. Nhưng làm thế nào tôi có thể đảm bảo rằng ví dụ: Ứng dụng 2 luôn chứa phiên bản mới nhất của Lib 1? Tôi có phải theo dõi các thay đổi trên Lib 1 và cập nhật Ứng dụng 2 theo cách thủ công ngay khi Lib thay đổi không? Hoặc bằng cách nào đó tôi có thể buộc Visual Studio luôn sử dụng phiên bản mới nhất của một dự án bên ngoài bằng cách nào đó?

Chỉnh sửa: Trên TFS, chỉ có một Bộ sưu tập Dự án nhóm TFS, chứa một Dự án nhóm TFS. Dự án nhóm chứa một Giải pháp Visual Studio lớn, chứa một số thư mục chứa (xem cấu trúc bên trên) với mỗi thư mục chứa nhiều dự án VS.

Câu hỏi của tôi là bây giờ, bạn sẽ tổ chức lại như thế nào:

  1. Các dự án nhóm TFS
  2. Dự án VS

1
Khi bạn nói "một giải pháp TFS lớn", bạn đang nói về Bộ sưu tập dự án nhóm TFS hay Dự án nhóm TFS hoặc giải pháp Visual Studio?
Zugbo

Như Zugbo đã nói, tôi nghĩ rằng bạn cần có được thuật ngữ phù hợp trước khi bất kỳ ai có thể giúp trả lời điều này, vì dường như bạn đang trộn lẫn các dự án nhóm TFS với các giải pháp Visual Studio. Bạn có thể có một Dự án nhóm duy nhất với nhiều giải pháp.
Tom Robinson

Xin lỗi vì đã cung cấp quá ít chi tiết. Tôi sẽ chỉnh sửa câu hỏi ban đầu của tôi.
dhh

Câu trả lời:


11

Gắn bó với một Dự án nhóm TFS, việc nhiều người trở nên khó khăn khi cố gắng nâng cấp và có một số hạn chế khi nói đến các mục công việc của dự án nhóm chéo. Thay vào đó, bạn nên sử dụng nhiều Khu vực và Lặp lại.

Chia giải pháp VS của bạn thành nhiều giải pháp, mỗi giải pháp cho một ứng dụng chính. Điều này sẽ tăng tốc độ xây dựng cục bộ rất nhiều, cũng như máy chủ xây dựng.

TFS2012 có một khái niệm mới gọi là Nhóm, tạo một nhóm cho mỗi ứng dụng và đặt các lần lặp và tồn đọng mặc định cho mỗi ứng dụng. Bằng cách này, bạn có thể quản lý tồn đọng cho từng nhóm hoặc xem nhóm gốc để xem một hồ sơ tồn đọng. Sau đó, bạn có thể quản lý chạy nước rút ở cấp độ ứng dụng hoặc tổng thể tùy thuộc vào những gì phù hợp với bạn.

Tạo các gói NuGet cho tất cả các thư viện được tham chiếu của bên thứ 3 chưa có. Lưu trữ chúng trong một kho lưu trữ riêng (thư mục chia sẻ windows) và kích hoạt tính năng khôi phục gói cho NuGet bằng cách nhấp chuột phải vào mọi giải pháp và bật nó (cũng cho phép khôi phục gói để tải xuống các gói trong vs cài đặt).

Nếu bạn có bất kỳ thư viện nội bộ được chia sẻ nào thì hãy tạo các gói NuGet cho chúng và tạo một giải pháp vs chỉ chứa thư viện đó. Thêm lệnh xây dựng bài đăng để tạo gói nuget hoặc mở rộng mẫu xây dựng tfs của bạn để thực hiện (có một số mẫu ngoài đó đã làm điều này).


+1 - ước gì tôi có thể làm cho nó nhiều hơn. Việc buộc cấu trúc repo vào cấu trúc ứng dụng là một công thức cho các vấn đề khi cấu trúc ứng dụng thay đổi. Hãy để sự phân tách 'mềm' của các tệp Giải pháp, Vùng và Lặp lại đóng vai trò là ranh giới và chia sẻ những gì hợp lý để chia sẻ.
Telastyn
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.