Part II- Chapter 3 --Team Development with Visual Studio Team Foundation Server

Nguyễn Thị Như Quỳnh — Fri, 11 Sep 2009 16:32:09 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/12/2009 12:32:09 AM

Part II- Chapter 3 --Team Development with Visual Studio Team Foundation Server

Download tài liệu này tại đậy.

Chương 3 - Kết cấu các Project và Solution trong Source Control

Objectives

Kết cấu các project và solution của Microsoft® Visual Studio® Team System một cách phù hợp.
Biết được khi nào sử dụng multiple solution và khi nào sử dụng một single solution.
Xác định những cấu trúc thích hợp cho những đội nhỏ, vừa và lớn(small, medium-size and very large teams).

Overview

Chương này giải thích các tùy chọn khác nhau cho cấu trúc những tập tin project và solution của Visual Studio trong một sự quản lý thích hợp đối với nhóm phát triển. Visual Studio sử dụng những file solution (.sln) để nhóm các file dự án Visual Studio (.csproj and .vbproj) lại với nhau. Quyết định để kết cấu những project và solution như thế nào là một quyết định quan trọng vì các pattern(mô hình) mà bạn chọn có một số các hiệu ứng phụ. Thí dụ, các thành viên của những nhóm phát triển tác động dễ dàng đến việc kéo và đẫy(push and pull) các solution và project đến và từ source control, cơ chế mà bạn sử dụng để tham chiếu(reference) các dependency và cũng như là các processes.

Nếu bạn đang làm việc trên một dự án nhỏ bạn có thể sử dụng một single solution để chứa tất cả các file project của bạn. Nếu bạn đang làm việc trên một dự án phát triển phần mềm với một số lượng lớn các file project , bạn nên sử dụng những file multiple solution để nhóm các project có liên quan mà tương ứng với nhóm các chức năng của bạn trong tổng thể dự án nhóm. Tùy thuộc vào kịch bản cụ thể bạn có thể cũng cần một tập tin single solution để nhóm tất cả các file project lại với nhau.

Sử dụng chương này như thế nào

Sử dụng chương này để chọn một phương pháp tiếp cận cho việc kết cấu Visual Studio solution và project của bạn. Để đạt được lợi ích tốt nhất từ chương này, bạn nên:

Use the strategies list(Sử dụng danh sách các chiến thuật). Sử dụng danh sách các chiến lược khởi đầu như: single solution, partitioned solution, và multiple solutions để nhanh chóng đánh giá phương pháp tiếp cận tốt nhất cho kịch bản của bạn.
Đọc những phần kịch bản mà có liên quan nhiều nhất đến nhu cầu của bạn. Đọc phần mô tả làm thế nào để triển khai các tùy chọn mà chọn đã chọn.
Đọc chương 4, "Structuring Projects and Solutions in Team Foundation Server Source Control" kế tiếp. Chương 4 giới thiệu cho bạn những cân nhắc quan trọng nên nhớ khi lưu trữ code trong Team Foundation Server (TFS) source control.
Đọc chương 6, "Managing Source Control Dependencies in Visual Studio Team System". Kết cấu project tác động đến các chiến lược có sẵn cho bạn khi quản lý những thành phần phụ thuộc qua các project và solution. Để biết thêm thông tin về bằng cách nào để quản lý các phụ thuộc, hãy đọc chương 6.

• Đọc các chủ đề How To kèm theo. Đọc các chủ đề How To (Làm như thế nào để ) và đi theo từng bước các thao tác khác nhau được thảo luận trong chương này:

How To: Kết cấu ASP.NET Applications trong Visual Studio Team Foundation Server.
How To: Kết cấu Windows Applications trong Visual Studio Team Foundation Server.
How To: Kết cấu những thư mục Source Control của bạn trong Visual Studio Team Foundation Server.

Những chiến lược cho cấu trúc Solution và Project

Ba chiến lược chung nhất được sử dụng cho việc kết cấu các file solution và project là:

Single solution. Nếu bạn làm việc trên một hệ thống nhỏ, hãy tạo một single solution và đặt tất cả các file dự án của bạn trên đó.
Partitioned solution. Nếu bạn làm việc trên một hệ thống lớn, sử dụng những multiple solution để nhóm các project liên quan lại với nhau. Tạo các solution để nhóm một cách hợp lý các nhóm nhỏ project mà một nhà phát triển hầu như muốn chỉnh sửa như là một tập hợp, và sau đó tạo một master Solution (solution chủ) để chứa tất cả các dự án của bạn.Phương pháp tiếp cận này làm giảm bớt số lượng data cần được lấy từ source control khi bạn chỉ cần làm việc trên những project cụ thể.
Multiple solutions. Nếu bạn đang làm việc trên một hệ thống rất lớn mà yêu cầu hàng chục project hay nhiều hơn , hãy sử dụng multiple solution để làm việc trên các sub-systems(hệ thống con) nhưng đối với dependency mapping và performance reasons không tạo một master solution mà chứa tất cả các project.

Nói chung, bạn nên:

Sử dụng chiến lược một single solution nếu kết quả solution không quá lớn để load vào Visual Studio.
Sử dụng multiple solutions để tạo những specific views trên các sub-systems của ứng dụng của bạn.
Sử dụng multiple solutions để giảm thời gian load một solution và giảm thời gian build cho các nhà lập trình.

Hãy nhớ những điều sau khi thiết kế một cấu trúc project và solution:

Mỗi project đều tạo ra một assembly tại thời gian build. Bắt đầu bởi việc xác định assembly nào bạn muốn tạo và sau đó sử dụng nó để quyết định những project nào bạn cần. Sử dụng nó để quyết định phần code cơ bản nào của bạn được xem như là nhân tố trong các project.
Bắt đầu với cấu trúc single solution đơn giản nhất. Chỉ thêm các phần phức tạp vào kết cấu của bạn khi nó thật sự cần thiết.
Khi thiết kế một kết cấu multi-solution:

Xem xét tính độc lập của dự án. Hãy thử nhóm các project có phụ thuộc vào nhau như là những phần của cùng một solution. Điều này cho phép bạn sử dụng các tham chiếu project trong phạm vi solution của bạn. Bằng cách sử dụng các project references thay vì file references, cho phép Visual Studio để xây dựng cấu hình (debug/release) được đồng bộ hoá , và để theo dõi các version để xác định xem khi nào thì các project cần được built lại. Cố gắng giảm thiểu số lượng các tham chiếu qua các solution và project.

Xem xét sự chia sẻ source. Đặt những project được chia sẻ cùng một source trong cùng một solution.

Xem xét cấu trúc đội. Kết cấu những solution của bạn để thực hiện nó một cách dễ dàng cho các đội làm việc cùng nhau trên một tập các project.

Giữ một dãy kết cấu project để dễ dàng nhóm các project vào trong các solution mà không cần phải thay đổi cấu trúc file hệ thống hay thư mục source control .

Single Solution

Nếu bạn làm việc trong một hệ thống nhỏ, hãy xem xét sử dụng một single Visual Studio solution để chứa tất cả các project của bạn. Cấu trúc này đơn giản hoá việc phát triển, vì tất cả các code đã có sẵn khi bạn mở các solution. Chiến lược này cũng giúp bạn dễ dàng để thiết lập references, bởi vì tất cả các references đều nằm giữa những project trong solution của bạn. Bạn có thể vẫn còn cần phải sử dụng các tập tin references để tham chiếu đến các assembly của bên thứ ba, như là mua các thành phần(component) , mà ở bên ngoài solution của bạn. Hình 3.1 hiển thị phương pháp tiếp cận single solution .

Hình 3.1 Single Solution Approach

Những lí do chính để chọn cấu trúc này bao gồm:

Bạn có thể giữ các build script đơn giản.
Bạn có thể map(ánh xạ) dể dàng các project có tính phụ thuộc ngang nhau trong solution.

Bạn nên sử dụng cấu trúc này nếu tất cả các lập trình viên sử dụng cùng một solution và có cùng một tập các project. Điều này có thể là một vấn đề cho các hệ thống thống lớn nơi mà bạn muốn tổ chức các project bằng các hệ thống con hay các chức năng .

Partitioned Solution

Nếu bạn làm việc với một hệ thống lớn, xem xét việc sử dụng các multiple solution, mỗi cái đại diện một hệ thống con trong ứng dụng của bạn. Những solution này có thể được các lập trình viên sử dụng để làm việc trên những phần nhỏ hơn của hệ thống mà không có việc load tất cả các code trên tất cả các project. Thiết kế cấu trúc solution của bạn với bất kì project nào mà có phụ thuộc giữa các nhóm với nhau. Điều này cho phép bạn sử dụng các project reference hơn là các file reference. Hãy xem xét luôn việc tạo một tập tin master solution để chứa tất cả các project. Bạn có thể sử dụng điều này để build toàn bộ ứng dụng của bạn.

Lưu ý: Không như phiên bản trước của Visual Studio, Visual Studio 2005 dựa theo MSBuild. Hiện thời nó cho phép tạo những cấu trúc solution mà không bao gồm tất cả các project reference và vẫn còn build không có các error. Miển là master solution được build trước, tạo ra các binary output từ các project, MSBuild có thể theo sau các project references bên ngoài những sự ràng buộc của solution và build thành công của bạn. Nó chỉ làm việc nếu bạn sử dụng project references, không phải là file references. Bạn có thể build thành công các solution được tạo bằng phương pháp này từ Visual Studio build theo các dòng lệnh và từ IDE, nhưng mặc định là không được với Team Build . Để build thành công với Team Build hãy sử dụng master solution bao gồm tất cả các project và các phụ thuộc.

Hình 3.2 Hiển thị phương pháp tiếp cận partitioned solution.

Hình 3.2 Partitioned Solution Approach

Khi làm việc với các multiple solution, sử dụng một dãy cấu trúc các file cho tất cả các project của bạn. Một thí dụ điển hình là một ứng dụng có một Microsoft Windows® Forms project, một ASP.NET project, một Windows service, và một tập các class library project được chia sẻ bởi một hay tất cả các project này.

Bạn có thể sử dụng dãy các cấu trúc sau cho tất cả các project:

§ /Source

/WinFormsProject
/WebProject
/WindowsServiceProject
/ClassLibrary1
/ClassLibrary2
/ClassLibrary3
Web.sln
Service.sln
All.sln

Giữ dãy các cấu trúc này cung cấp nhiều sự linh hoạt và khả năng để sử dụng các solution cho các trình bày khác nhau trên những project. Cấu trúc thư mục vật lý xung quanh các file solution này thay đổi rất khó, đặc biệt nếu bạn nhận ra là bạn cần tái sử dụng lại một class library từ một solution khác.

Lí do để sử dụng cấu trúc này bao gồm:

Hiệu suất được cải thiện khi tải và xây dựng các ứng dụng sub-solution .
Các sub-solution có thể được sử dụng để tạo các ý định trên các tập project dựa trên các đội phát triển con hay các ranh giới của việc chia sẻ code.
Bạn có thể sử dụng master solution để build toàn bộ ứng dụng.
Bạn có thể dễ dàng map(ánh xạ) các phần dependency trên các project trong mỗi sub-solution.
Nó giảm sự phức tạp nếu các solution broken up một cách logic. Thí dụ sự phá vỡ các solution cùng với các tuyến kĩ thuật và chức năng đã làm cho các lập trình viên mới hiểu được một cách dễ dàng solution nào đang được thực thi.

Lí do chính để không sử dụng cấu trúc này :

Tăng chi phí cho sự bảo trì các solution. Thêm một project mới có thể đề ra yêu cầu phải thay đổi các tập tin multiple solution .

Multiple Solutions

Nếu bạn làm việc trên một solution rất lớn, yêu cầu hàng tá các project, bạn có thể gặp phải việc mở rộng giới hạn của các solution . Trong kịch bản này, di chuyển ứng dụng của bạn vào những multiple solution nhưng không tạo một master solution cho toàn bộ ứng dụng application bởi vì tất cả các reference bên trong mỗi solution là các project references. Những tham chiếu đến các project bên ngoài mỗi solution (thí dụ cho các libraries hay project của bên thứ ba trong sub-solution khác) là các file references. Điều này có nghĩa là không thể có "master" solution.

Thay vào đó, bạn phải sử dụng một script hiểu trật tự cần phải được built của các solution. Một trong những nhiệm vụ bảo trì liên quan đến một kết cấu multiple-solution là chắc chắn rằng những lập trình viên không cố ý tạo ra các vòng tròn tham chiếu(reference) giữa các solution. Kết cấu này yêu cầu những script(tập lệnh) được thiết kế phức tạp và những mối quan hệ phụ thuộc rõ ràng. Trong kết cấu này không thể build ứng dụng trong nó với Visual Studio. Thay vào đó, bạn có thể sử dụng TFS Team Build hay MSBuild một cách trực tiếp.

Hình 3.3 hiển thị phương pháp tiếp cận multiple solutions.

Hình 3.3 Multiple Solution Approach

Bạn nên sử dụng kết cấu này để giải quyết sự thực thi Visual Studio IDE và mở rộng các giới hạn cho các ứng dụng rất lớn.

Một lí do cho việc không sử dụng cấu trúc này là vì nó yêu cầu một build script phức tạp để xử lý các phụ thuộc giữa các sub-solutions bằng cách build các solutions theo một trình tự đúng.

Large Project Considerations

Phân biệt những nhóm phát triển lớn với các nhóm nhỏ hơn theo nhiều cách:

• Họ đòi hỏi một kết cấu chi tiết và tổng hợp phức tạp hơn.

Họ có nhiều khả năng hơn về quản lý các thành phần phụ thuộc trên các solutions và các nhóm projects.
Họ có nhiều khả năng duy trì các thiết kế cho các thành phần và các nhóm.

Một phương pháp tiếp cận partitioned solution làm việc tốt với hầu hết các dự án lớn vì nó cung cấp các solution một cách mềm dẻo trong khi duy trì một single solution mà bạn có thể sử dụng để build các ứng dụng. Nếu ứng dụng của bạn đủ lớn để bạn thực hiện mở rộng giới hạn solution, hãy sử dụng phương pháp multiple solution.

Tổng kết

Sử dụng một single solution cho các project nhỏ mà các project đó không cần để phân vùng source của bạn vào các solution con riêng biệt.

Sử dụng một partitioned solution cho tập các nhóm project con mà một lập trình viên có thể chỉnh sửa nó như là một tập hợp, và sau đó tạo một master solution chứa tất cả các project của bạn.

Sử dụng multiple solutions để tạo một cái nhìn cụ thể trên những hệ thống con và để giảm việc load và thời gian build của ứng dụng của bạn.

Một partitioned solution làm việc tốt với hầu hết các dự án lớn vì nó cung cấp các solution một cách mềm dẻo trong khi duy trì một single solution mà bạn có thể sử dụng để build các ứng dụng.

Additional Resources

Để có thêm thông tin về cấu trúc project và solution (mặc dầu không được áp dụng trực tiếp trong Team Foundation Server), hãy xem "Team Development with Visual Studio .NET and Visual SourceSafe" tại đây: http://msdn2.microsoft.com/en-us/library/ms998208.aspx

Part II- Chapter 3 --Team Development with Visual Studio Team Foundation Server

Nguyễn Thị Như Quỳnh — Fri, 11 Sep 2009 16:27:30 GMT

Revision 3 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/12/2009 12:27:30 AM