TFS - Team Foundation System

Chủ đề: Làm Thế Nào

Nguyễn Thị Như Quỳnh — Sun, 21 Feb 2010 20:29:49 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/22/2010 4:29:49 AM

Sau đây là tài liệu tập hợp tất cả các bài Làm Thế Nào, bạn có thể download tại đây:

How To

Team Foundation Server Resources

Nội Dung

patterns & practices
Team Foundation Related Web Sites
Partners and Service Providers
Newsgroups and Forums
Microsoft Team Foundation Blogs
Service Packs
Training

patterns & practices

Để có thêm thông tin về các patterns và các practices, hãy tham khảo trang chủ Microsoft patterns & practices tại http://msdn.microsoft.com/practices/

CodePlex Sites

Team Foundation Branching Guidance tại http://www.codeplex.com/BranchingGuidance
Guidance Explorer tại http://www.codeplex.com/guidanceExplorer
Team Foundation Server Guide tại http://www.codeplex.com/TFSGuide
Team Foundation Server Guidance tại http://www.codeplex.com/VSTSGuidance

Team Foundation Related Web Sites

Team Foundation Server Team Center tại http://msdn2.microsoft.com/en-us/teamsystem/aa718934.aspx
Team Foundation Server FAQ tại http://msdn2.microsoft.com/en-us/teamsystem/aa718916.aspx
Team System Videos and Presentations tại http://msdn2.microsoft.com/en-us/teamsystem/aa718837.aspx
Team Foundation Server MSDN Documentation tại http://msdn2.microsoft.com/en-us/library/ms181232(vs.80).aspx
Tải về Team Foundation Server Installation Guide tại http://go.microsoft.com/fwlink/?linkid=40042

Partners and Service Providers

Partner catalog tại http://catalog.vsipmembers.com/catalog/
Teamprise cross platform support tại http://www.teamprise.com/
Scrum support from Conchango tại http://www.conchango.com/Web/Public/Content/Home.aspx
ComponentSoftware source control migration tại

http://www.componentsoftware.com/Products/converter/index.htm

Requirements management from Borland tại http://www.borland.com/
Business Process Modeling from RavenFlow tại http://www.n8systems.com/

Forums

Danh sách các MSDN Forums có thể tìm thấy ở đây: http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=5&SiteID=1

Forum	Address
Team Foundation Server - General	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=22&SiteID=1
Team Foundation Server - Setup	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=68&SiteID=1
Team Foundation Server - Administration	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=477&SiteID=1
Team Foundation Server - Build Automation	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=481&SiteID=1
Team Foundation Server - Power Toys	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=930&SiteID=1
Team Foundation Server - Process Templates	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=482&SiteID=1
Team Foundation Server - Reporting & Warehouse	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=480&SiteID=1
Team Foundation Server - Team System Web Access	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=1466&SiteID=1
Team Foundation Server - Version Control	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=478&SiteID=1
Team Foundation Server - Work Item Tracking	http://forums.microsoft.com/MSDN/ShowForum.aspx?F orumID=479&SiteID=1

Microsoft Team Foundation Blogs

Ask Burton http://blogs.msdn.com/askburton/
Brian Harry http://blogs.msdn.com/bharry/
Buck Hodges http://blogs.msdn.com/buckh/
James Manning http://blogs.msdn.com/jmanning/
Rob Caron http://blogs.msdn.com/robcaron/
Team Foundation Blog at http://blogs.msdn.com/team_foundation

Service Packs

Visual Studio 2005 SP1 at http://msdn2.microsoft.com/en-gb/vstudio/bb265237.aspx
Microsoft® Visual Studio® 2005 Team Foundation Server Service Pack 1 tại http://www.microsoft.com/downloads/details.aspx?FamilyId=A9AB638C-04D2-4AEE-8AE8-9F00DD454AB8
Visual Studio 2005 Service Pack 1 Update for Windows Vista tại

http://www.microsoft.com/downloads/details.aspx?FamilyID=90e2942d-3ad1-4873-a2ee-4acc0aace5b6&displaylang=en

SQL Server 2005 Service Pack 2 tại http://technet.microsoft.com/en-us/sqlserver/bb426877.aspx

Training

Một danh sách các công ty đào tạo có thể tìm thấy ở đây: http://msdn2.microsoft.com/en-us/teamsystem/aa718793.aspx

Developmentor tại http://www.develop.com/
Pluralsight tại http://www.pluralsight.com

• Notion Solutions tại http://www.notionsolutions.com

Vậy là phần này mình đã hoàn thành xong và kết thúc tại đây.

Mình hi vọng là các bạn sẽ tìm được tài liệu cần thiết. Nếu có gì thiếu sót, các bạn có thể góp ý tại đây, hoặc gửi mail cho mình, mình sẽ sửa lại. Mail của mình là kpopyo@gmail.com.

Thanks,

Quỳnh

Làm Thế Nào Để: Tạo Custom Check-in Policies Trong Visual Studio Team Foundation Server

Nguyễn Thị Như Quỳnh — Sun, 21 Feb 2010 20:21:46 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/22/2010 4:21:46 AM

Được áp dụng cho

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)
Microsoft Visual Studio Team System

Tóm tắt

Chủ đề Làm Thế Nào này sẽ dẫn bạn đi qua quy trình của việc tạo, đăng kí, và áp dụng một chính sách check-in policy tùy ý cho những chính sách TFS. Check-in policy cho phép bạn kích hoạt các quy tắc bất cứ khi nào một lập trình viên cố gắng thực hiện check-in một source file, để đảm bảo là source file đang được check-in đáp ứng được một tập hợp các tiêu chuẩn cụ thể. Như là một thí dụ, chỉ đề Làm Thế Nào này sử dụng một chính sách policy tùy ý để thực hiện các check-in comment được cung cấp với tất cả các check-in. Để thực thi một chính sách check-in policy tùy ý, bạn hãy tạo một lớp class có nguồn gốc từ PolicyBase và thực thi giao diện IPolicyDefinition và IPolicyEvaluation interfaces. Bạn đăng kí policy assembly trong Microsoft Windows® registry và bạn áp dụng chính sách policy cho dự án nhóm của bạn.

Nội dung

Chủ đề
Xem trước
Trước khi bạn bắt đầu
Tóm tắt các bước
Bước 1 - Tạo và Build một Custom Policy Class.
Bước 2 - Đăng kí Custom Policy Class trong Windows Registry
Bước 3 - Áp dụng Custom Policy.
Bước 4 - Xác nhận Custom Policy.
Những mã nguồn bổ sung

Chủ đề

Tìm hiểu một chính sách custom check-in policy là gì
Tìm hiểu làm thế nào để tạo, đăng kí và áp dụng các chính sách custom check-in policy.

Xem trước

Các chính sách check-in policy thực thi các ràng buộc bất cứ khi nào các tập tin được check trong source control. Team Foundation Server cung cấp một số các chính sách out-of-box check-in policy gồm các chính sách policy để kiểm tra rằng các unit test được chạy và được thông qua, các chính sách policy để thực thi các phân tích code tĩnh(static code analysis) để đảm bảo là phần code đáp ứng được các tiêu chuẩn về code và các hướng dẫn .NET guidelines, và các chính sách policy để kiểm tra là các work item có được liên kết với các check in. Các công cụ Microsoft Visual Studio 2005 Team Foundation Power Tool cũng cung cấp một số các chính sách check-in policy bổ sung. Trong đề tài Làm Thế Nào này, bạn sẽ tìm hiểu làm thế nào để tạo, đăng kí và áp dụng một chính sách custom policy. Chính sách thí dụ đảm bảo là các lập trình viên phải cung cấp các check-in comment bất cứ khi nào họ check in một file.

Trước khi bắt đầu

Hãy lưu ý là, để tạo một chính sách check-in policy, bạn phải có các Manipulate security settings permission được thiết lập là Allow.

Tóm tắt các bước

Bước 1 - Tạo và Build một Custom Policy Class.
Bước 2 - Đăng kí Custom Policy Class trong Windows Registry
Bước 3 - Áp dụng Custom Policy.
Bước 4 - Xác nhận Custom Policy.

Bước 1 - Tạo và Build một Custom Policy Class

Trong bước khởi đầu này, bạn tạo một lớp chính sách theo ý bạn bằng cách suy ra từ lớp PolicyBase base class trong Microsoft.TeamFoundation.VersionControl.Client namespace. Bằng cách kế thừa từ lớp cơ bản này, lớp của bạn thực thi các IPolicyDefinition và IPolicyEvaluation interfaces. Phần mã chính sách ví dụ bên dưới buộc một lập trình viên cung cấp các chú thích check-in comment bất cứ khi nào anh ta hay cô ta check in một source file.

1. Sử dụng Visual Studio để tạo một dự án Visual C#® class library project mới.

2. Thêm một assembly reference đến System.Windows.Forms.dll. Bạn sử dụng assembly này để hiển thị các hộp tin nhắn message boxes.

3. Thêm một assembly reference đến

Microsoft.TeamFoundation.VersionControl.Client.dll. Mặc định, nó được cài đặt trong thư mục sau:\Program Files\Visual Studio 2005 Team Foundation Server\Tools

4. Thay thế bộ khung lớp code thực thi bằng phần source sau. Hãy lưu ý là lớp này kế thừa lớp cơ sở PolicyBase và được đánh dấu là serializable.

using System;

using System.Windows.Forms;

using Microsoft.TeamFoundation.VersionControl.Client;

[Serializable]

public class CheckForCommentsPolicy : PolicyBase

{

public override string Description

{

get { return "Remind users to add meaningful comments to their checkins"; }

}

// This is a string that is stored with the policy definition on the source

// control server. If a user does not have the policy plug-in installed, this string

// is displayed. You can use this to explain to the user how they should

// install the policy plug-in.

public override string InstallationInstructions

{

get { return "To install this policy, read InstallInstructions.txt."; }

}

// This string identifies the type of policy. It is displayed in the

// policy list when you add a new policy to a Team Project.

public override string Type

{

get { return "Check for Comments Policy"; }

}

// This string is a description of the type of policy. It is displayed

// when you select the policy in the Add Check-in Policy dialog box.

public override string TypeDescription

{

get { return "This policy will prompt the user to decide whether or not they should be allowed to check in."; }

}

// This method is called by the policy framework when you create

// a new check-in policy or edit an existing check-in policy.

// You can use this to display a UI specific to this policy type

// allowing the user to change the parameters of the policy.

public override bool Edit(IPolicyEditArgs args)

{

// Do not need any custom configuration

return true;

}

// This method performs the actual policy evaluation.

// It is called by the policy framework at various points in time

// when policy should be evaluated. In this example, the method

// is invoked when various asyc events occur that may have

// invalidated the current list of failures.

public override PolicyFailure[] Evaluate()

{

string proposedComment = PendingCheckin.PendingChanges.Comment;

if (String.IsNullOrEmpty(proposedComment))

{

return new PolicyFailure[] {

new PolicyFailure("Please provide some comments about your check-in", this) };

}

else

{

return new PolicyFailure[0];

}

// This method is called if the user double-clicks on

// a policy failure in the UI. In this case a message telling the user

// to supply some comments is displayed.

public override void Activate(PolicyFailure failure)

{

MessageBox.Show("Please provide comments for your check-in.", "How to fix your policy failure");

}

// This method is called if the user presses F1 when a policy failure

// is active in the UI. In this example, a message box is displayed.

public override void DisplayHelp(PolicyFailure failure)

{

MessageBox.Show("This policy helps you to remember to add comments to your check-ins.", "Prompt Policy

Help");

}

Bước 2 - Đăng kí Custom Policy Class trong Windows Registry

Trong bước này, bạn thêm một mục vào Windows registry để chính sách policy của bạn xuất hiện trong hộp thoại Add Check-in Policy. Lưu ý là bạn phải cài đặt các policy assembly trên bất kì máy tính nào có nhu cầu tham chiếu đến các assembly đó. Gồm có các máy tính của người quản trị của dự án nhóm, là người cần liên kết chính sách policy với dự án nhóm và trên các máy tính của các thành viên nhóm là nơi mà chính sách policy thực sự được thực thi.

Quan trọng: Chính sách policy được đánh giá trên client khi một lập trình viên check in một tập tin.

1. Khởi động Regedit.exe và xác định ví trí quan trọng sau HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Checkin Policies

Các chính sách đã đăng kí được liệt ở phần bên phải.

2. Click phải trong hộp bên phải, trỏ đến phần New, và sau đó click String Value.

3. Hãy nhập tên của chính sách custom policy dynamic link library (DLL), mà không có phần mở rộng DLL ; CheckForCommentsPolicy trong ví dụ trên.

Quan trọng: Tên của chính sách phải phù hợp với tên tập tin DLL một cách chính xác, mà không có phần mở rộng DLL.

4. Click đôi vào chuỗi giá trị mới và thiết lập giá trị của nó thành đường dẫn giá trị đầy đủ và tên tập tin .dll chứa chính sách của bạn.

Bước 3 - Áp dụng Custom Policy

Trong bước này bạn thêm custom policy vào team project của bạn. Điều này đảm bảo là chính sách policy có giá trị mỗi khi một lập trình viên check in một tập tin vào team project này.

1. Trong Team Explorer, click phải lên team project của bạn, trỏ đến Team Project Settings và sau đó click Source Control.

2. Click vào thẻ Check-in Policy và sau đó click Add.

3. Hãy chọn tùy chọn Check for Comments Policy và click OK và sau đó OK lần nữa.

Bây giờ chính sách policy đã được áp dụng mỗi khi một lập trình viên check in một tập tin trong team projecy này.

Bước 4- Xác nhận Custom Policy

Trong bước này, bạn check-in một source file để đảm bảo là custom policy làm việc chính xác.

1. Thực hiện một thay đổi cho một tập tin source và sau đó check-in tập tin mà không cung cấp một chú thích check-in comment.

2. Xác nhận là check-in đã bị ngăn chặn vì các quy luật của chính sách(policy rule) không phù hợp.

3. Hãy thêm một vài chú thích comment và hoàn thành check-in. Với comment cung cấp cho check-in sẽ thực hiện thành công và bạn sẽ thấy một thông báo chính sách thất bại(policy failure notification).

Mã nguồn bổ sung

Để tìm hiểu thêm về làm thế nào để tùy chỉnh một check-in policy, hãy xem "Walkthrough: Customizing Check-in Policies and Notes" tại http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx
Để xem các đoạn code đơn giản cấm chọn các mẫu trên check-in, hãy xem "Check-in Policy to Disallow Certain Patterns" tại đây http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx
Để xem các đoạn code đơn giản mà thực thi các comment trên check-in, hãy xem "Sample Check-in Policy: Make Sure the Comment Isn't Empty" tại đây http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx

Để tìm hiểu làm thế nào để đăng kí một check-in policy mới, hãy xem "I've Made a New Check-In Policy! How Do I Add It?" tại đây http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx

Làm thế nào: Tạo một báo cáo "Risk over Time" Report đối với Visual Studio Team Foundation Server

Nguyễn Thị Như Quỳnh — Sun, 21 Feb 2010 20:20:02 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/22/2010 4:20:02 AM

Được áp dụng cho

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)
Microsoft Visual Studio Team System (VSTS)
Microsoft SQL Server^TM Reporting Services

Tóm tắt

Chủ đề Làm thế nào này sẽ dẫn bạn quan quy trình của việc tạo mới một báo cáo report mà sẽ hiển thị xu hướng của các Risk work items theo thời gian như thế nào. Đề tài này sẽ trình bày cho bạn làm cách nào để xuất bản nó đến team reporting portal trong TFS.

Nội dung

Chủ đề
Xem trước
Tóm tắt các bước
Trước khi bạn bắt đầu
Bước 1 - Tạo mới một Reporting Project
Bước 2 - Tạo các Data Sources
Bước 3 - Tạo mới Report trong Project của bạn
Bước 4 - Chỉnh sửa Report
Bước 5 - Triển khai Report đến Team Foundation Server của bạn
Bước 6 - Kiểm thử Report
Mã nguồn bổ sung

Chủ đề

Tạo một reporting project trong Visual Studio.
Tạo mới một Risk over Time report trong reporting project.
Xuất bản Risk over Time report đến report server.

Xem trước

Các report mà đi kèm với VSTS là SQL Server Reporting Services reports. Bạn có thể chỉnh sửa những report tốt hơn hay tạo các report cho riêng bạn bằng cách sử dụng SQL Server 2005 Reporting Services Designer bên trong Visual Studio (Business Intelligence Development Studio[BISD]), kèm với các công cụ SQL Server 2005 client tools. Để tạo một report theo ý bạn, bạn tạo một Report Project trong Visual Studio và sau đó tạo data sources để kết nối đến các TFS database có liên quan và Online Analytical Processing (OLAP) database. Chủ đề Làm thế nào này trình bày làm cách nào để tạo một báo cáo report đơn giản từ scratch - Risk over Time report mà xác định số lượng các Risk work items qua một giai đoạn thời gian.

Tóm tắt các bước

Bước 1 - Tạo mới một Reporting Project
Bước 2 - Tạo các Data Sources
Bước 3 - Tạo mới Report trong Project của bạn
Bước 4 - Chỉnh sửa Report
Bước 5 - Triển khai Report đến Team Foundation Server của bạn
Bước 6 - Kiểm thử Report

Trước khi bạn bắt đầu

Trước khi bạn có thể tùy chỉnh một báo cáo cho TFS, bạn phải đảm bảo là bạn có các yêu cầu cần thiết :

Bạn phải có Business Intelligence Development Studio (BIDS) được cài đặt trên máy mà bạn sẽ sử dụng để tùy chỉnh các report. Để xác nhận xem là BIDS được cài đặt chưa, hãy kiểm tra Visual Studio để biết là nếu bạn có tùy chọn về loại dự án Business Intelligence Project khi bạn tạo mới một dự án.
Tài khoản người dùng của bạn phải là một thành viên của Microsoft Analysis Server TfsWarehouseDataReaders security role trên server tầng data.
Tài khoản người dùng của bạn phải có các quyền quản trị về cơ sở dữ liệu TFSWarehouse database trên tầng data.
Tài khoản người dùng của bạn phải là một thành viên của SQL Server Reporting Services Publisher role trên server tầng application
Dự án phải chứa các Risk work items để báo cáo report hiển thị một số dữ liệu.

Bước 1 - Tạo mới một Reporting Project

Trong bước khởi đầu này, bạn tạo một dự án báo cáo mới để bạn có thể thêm một báo cáo mới vào dự án và sau đó chỉnh sửa báo cáo report. Thực hiện các bước sau để tạo một dự án báo cáo mới trong Visual Studio:

1. Click File, sau đó click New, và sau đó click Project.

2. Chọn loại Business Intelligence Project type.

3. Chọn mẫu Report Server Project template.

4. Thiết lập tên và vị trí của dự án Name và Location và sau đó click OK.

Bước 2 - Tạo các Data Sources

Để chỉnh sửa và xuất bản các report tùy chỉnh, đầu tiên bạn cần thêm các data source cho TFS data warehouse và OLAP cube. Mỗi lần những data source này được thêm vào dự án Visual Studio project thì report có thể lấy dữ liệu từ server.

Để tạo warehouse data source:

1. Trong Visual Studio Solution Explorer, click phải vào Shared Data Sources và sau đó click Add New Data Source.

2. Trên thẻ tab General, trong ô Name text box , hãy điền là TfsReportDS .

3. Chọn Microsoft SQL Server từ Type combo box.

4. Click vào button Edit....

5. Điền tên server tầng data của bạn.

6. Chọn TFSWarehouse database.

7. Click vào OK button hai lần để thêm data source.

Để tạo OLAP data source:

1. Trong Solution Explorer, click phải lên Shared Data Sources và sau đó click Add New Data Source.

2. Trên thẻ tab General, trong ô Name text box, nhập vào TfsOlapReportDS .

3. Chọn Microsoft SQL Server Analysis Services từ Type combo box.

4. Click vào Edit... button.

5. Điền tên server của tầng data.

6. Chọn TFSWarehouse database.

7. Click the OK button hai lần để thêm data source.

Bước 3 - Tạo một Report mới trong Project của bạn

Bây giờ thì các data source đã được thêm vào dự án của bạn và bạn có thể thêm một report mới.

Hãy thực hiện theo các bước sau để thêm một report mới vào dự án của bạn và tùy chỉnh nó:

1. Trong Solution Explorer, hãy click chuột phải lên Reports và sau đó chọn Add->New Item...

2. Chọn mẫu Report template.

3. Đặt tên cho report và click OK

Bước 4 - Chỉnh sửa Report

Sau khi bạn thêm một report vào dự án của bạn, bạn có thể chỉnh sửa report như sau:

1. Nếu Report Designer không tự động mở, hãy mở report để chỉnh sửa bằng cách click đôi vào nó trong Solution Explorer.

2. Click vào Dataset thả xuống và chọn <New Dataset...>.

3. Đặt tên cho dataset, thí dụ TestDataSet.

4. Hãy chọn TFSOlapReportDS (shared) và sau đó click OK.

5. Click vào ... button bên cạnh Build (chỉ bên dưới danh sách thả xuống Dataset) và sau đó chọn Team System.

6. Trong cây Dataset Tree, hãy mở rộng phần Measures.

7. Trong cây Dataset Tree, mở rộng phần Current Work Item.

8. Kéo Current Work Item Count vào cửa sổ truy vấn chính.

9. Trong cây Dataset Tree, thu lại phần Measures.

10. Cuộn Team Project xuống và kéo nó vào lưới Dimensions Grid.

11. Trong Dimensions Grid, click vào ô Filter Expression và chọn tên dự án nhóm của bạn. Điều này lọc những kết quả chỉ là dự án nhóm của bạn.

12. Mở rộng kích thước phần Work Item trong Dataset Tree.

13. Kéo WorkItem.WorkItemType từ Dataset Tree vào Dimensions Grid. Bạn có thể thấy System_WorkItemType thay vì là WorkItem.WorkItemType, nếu trường hợp này nó vẫn hoạt động, nhưng có nghĩa là bạn nên áp dụng SQL Server Service Pack

14. Kéo WorkItem.WorkItemType từ Dataset Tree vào cửa sổ truy vấn chính và thả nó ở phía trước cột tính work item. Bạn có thể nhìn thấy System_WorkItemType thay vì là WorkItem.WorkItemType, nếu là trường hợp nó vẫn còn hoạt động, nhưng có nghĩa là bạn nên áp dụng SQL Server Service Pack 2.

15. Trong Dimensions Grid, click vào ô Filter Expression và sau đó chọn loại Risk. Điều này sẽ lọc ra các kết quả là chỉ các loại Risk work item.

16. Trong Dataset Tree,hãy mở rộng kích thước Date.

17. Kéo giá trị kích thước Date vào cửa sổ truy vấn chính; thả nó trước cột loại work item.

18. Click vào Layout tab.

19. Hãy mở cửa số Toolbox window.

20. Kéo Chart từ Toolbox vào layout grid.

21. Chỉnh sửa kích thước của chart cho phù hợp.

22. Click phải lên chart và sau đó chọn Chart Type Line Smooth Line.

23. Hãy mở Datasets Pane.

24. Mở rộng data set của bạn, thí dụ, TestDataSet.

25. Highlight đồ thị để Data, Series và Category xuất hiện.

26. Thả Current_Work_Item_Count vào Drop Data Fields Here drop target box.

27. Thả Work_Item_Type vào Drop Series Fields Here drop target box.

28. Thả Date vào Drop Category Fields Here drop target box.

29. Click chuột phải vào đồ thị và sau đó chọn Properties.

30. Nhập một chủ đề cho đồ thị của bạn và sau đó click OK.

31. Click vào thẻ Preview để xem những report nào trong như vậy.

Bước 5 - Triển khai Report đến Team Foundation Server của bạn

Sau khi bạn đã tạo Risk over Time report, bạn có thể triển khai nó đến reporting portal của dự án nhóm của bạn bằng cách thực hiện các bước sau:

1. Trong Solution Explorer, click chuột phải trên report project và sau đó click Properties.

2. Hãy chắc là OverwriteDataSources được cài đặt là false.

3. Chỉnh sửa TargetDataSourceFolder để ánh xạ đúng tên của dự án bạn; thí dụ TargetDataSourceFolder = TestProject.

4. Chỉnh sửa TargetReportFolder để ánh xạ đúng tên của dự án bạn; thí dụ TargetDataSourceFolder = TestProject.

5. Chỉnh sửa TargetDataSourceFolder thành http://<data-tier servername>/reportserver; thí dụ: TargetDataSourceFolder = http://tfsrtm/reportserver.

6. Click OK.

7. Trong Solution Explorer, hãy click phải lên tạp tin .rdl và sau đó click Deploy.

8. Quan sát Output Pane để xác nhận là hoàn thành thành công.

Bước 6 - Kiểm thử report

Sau khi đã xuất bản report đến server chứa các report của dự án nhóm của bạn, bạn có thể kiểm thử để chắc là các report đó được triển khai một cách thành công:

1. Trong Team Explorer mở rộng nút dự án nhóm của bạn, click chuột phải lên Reports và sau đó hãy chọn Show Report Site.

2. Trên trang report site, hãy chọn report mà bạn vừa tạo.

3. Hãy xác nhận xem là report mà bạn tạo như bạn mon muốn.

Mã nguồn bổ sung

Để có thêm các hướng dẫn giải thích làm thế nào để làm việc với các dự án báo cáo,hãy xem "Reporting Services Tutorials" tại đây http://msdn2.microsoft.com/en-us/library/ms170246.aspx

Đối với MSDN article về chỉnh sửa các report, hãy xem "How to: Edit Reports in Report Designer" tại đây http://msdn2.microsoft.com/en-us/library/ms244655(VS.80).aspx

Để có thêm thông tin về các quy tắc bảo mật trong tầng data, hãy xem "Securing Access Through Analysis Services" tại đây http://msdn2.microsoft.com/en-us/library/ms174839.aspx

Để có thêm thông tin về các quy tắc bảo mật trong tầng application,hãy xem "Securing Reporting Services" tại đây http://msdn2.microsoft.com/en-us/library/ms157198.aspx

Làm Thế Nào Để: Tạo Một Custom Report Cho Visual Studio Team Foundation Server

Nguyễn Thị Như Quỳnh — Sun, 21 Feb 2010 20:18:37 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/22/2010 4:18:37 AM

Được áp dụng cho

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)
Microsoft Visual Studio Team System
Microsoft SQL Server^TM Reporting Services

Tóm tắt

Đề tài Làm thế nào này sẽ dẫn bạn đi qua quy trình tạo mới một custom report và chuyển nó vào team reporting portal trong Team Foundation Server.

Nội dung

Chủ đề
Xem trước
Tóm tắt các bước
Trước khi bạn bắt đầu
Bước 1 - Tạo mới một Reporting Project
Bước 2 - Tạo data sources
Bước 3 - Tạo mới một report trong project của bạn
Bước 4 - Chỉnh sửa report
Bước 5 - Triển khai các report đến Team Foundation Server của bạn
Bước 6 - Kiểm thử report
Mã nguồn bổ sung

Chủ đề

Tìm hiểu làm thế nào để tạo một reporting project trong Visual Studio
Tìm hiểu làm thế nào để tạo một báo cáo tùy ý mới trong reporting project
Tìm hiểu làm thế nào để xuất bản một báo cáo mới đến report server

Xem trước

Những báo cáo đi kèm với VSTS là các báo cáo SQL Server Reporting Services. Bạn có thể chỉnh sửa những báo cáo này cho tốt hơn hay là tạo các báo cáo theo ý bạn bằng cách sử dụng SQL Server 2005 Reporting Services Designer bên trong Visual Studio (Business Intelligence Development Studio), mà đi kèm với các công cụ của SQL Server 2005 client. Để tạo một báo cáo tùy ý, bạn tạo một dự án báo cáo trong Visual Studio, và sau đó tạo data sources để kết nối đến cơ sở dữ liệu TFS có liên quan và cơ sở dữ liệu Online Analytical Processing (OLAP) database.

Tóm tắt các bước

Bước 1 - Tạo mới một Reporting Project
Bước 2 - Tạo data sources
Bước 3 - Tạo mới một report trong project của bạn
Bước 4 - Chỉnh sửa report
Bước 5 - Triển khai các report đến Team Foundation Server của bạn
Bước 6 - Kiểm thử report

Trước khi bạn bắt đầu

Trước khi bạn có thể tùy chỉnh một báo cáo report cho Team Foundation Server, bạn phải đảm bảo là bạn có các yêu cầu cần thiết sau:

Bạn phải có Business Intelligence Development Studio được cài đặt trên máy mà bạn sẽ sử dụng để tùy chỉnh report. Để kiểm tra đã được cài đặt chưa, hãy kiểm tra xem Visual Studio để thấy nếu bạn có loại Business Intelligence Project khi bạn tạo một dự án mới.
Tài khoản người dùng của bạn phải là một thành viên của nhóm Microsoft Analysis Server TfsWarehouseDataReaders security role trên server của tầng data.
Tài khoản người dùng của bạn phải có quyền quản trị cơ sở dữ liệu TFSWarehouse database trên tầng data.
Tài khoản người dùng của bạn phải là thành viên của nhóm SQL Server Reporting Services Publisher role trên server của tầng application.

Bước 1 - Tạo mới một Reporting Project

Tạo mới một reporting project để bạn có thể thêm một report mới vào project và tùy chỉnh nó. Thực hiện theo các bước sau để tạo một reporting project mới trong Visual Studio:

1. Trong Visual Studio, click File, sau đó click New, và sau đó click Project.

2. Chọn loại Business Intelligence Project type.

3. Chọn mẫu Report Server Project template.

4. Đặt tên và vị trí cho dự án(project's Name and Location) và sau đó click OK.

Bước 2 - Tạo data sources

Để chỉnh sửa và xuất bản các report theo ý bạn, bạn cần thêm các data source cho kho dữ liệu Team Foundation Server data warehouse và OLAP cube. Mỗi lần các data source này được thêm vào dự án Visual Studio project thì báo cáo report có thể đẩy dữ liệu lên server.

Để tạo kho data source:

1. Trong Visual Studio Solution Explorer, click chuột phải lên Shared Data Sources và sau đó click Add New Data Source.

2. Trên thẻ tab General, hãy điền TfsReportDS vào ô Name text box.

3. Chọn Microsoft SQL Server từ hộp danh sách Type combo box.

4. Click vào Edit... button.

5. Điền tên server tầng data của bạn.

6. Chọn cơ sở dữ liệu TFSWarehouse database.

7. Click vào OK button hai lần để thêm data source.

Để tạo OLAP data source:

1. Trong Solution Explorer, click chuột phải vào Shared Data Sources và sau đó click Add New Data Source.

2. Trên thẻ General tab, điền TfsOlapReportDS vào ô Name text box.

3. Hãy chọn Microsoft SQL Server Analysis Services từ Type combo box.

4. Click vào Edit... button.

5. Điền tên server tầng data của bạn.

6. Chọn cơ sở dữ liệu là TFSWarehouse database.

7. Click vào OK button hai lần để thêm data source.

Bước 3 - Tạo mới một report trong project của bạn

Bây giờ thì các data sources đã được thêm vào dự án của bạn, bạn có thể thêm một báo cáo report mới.

Thực hiện các bước sau để thêm mới một report vào dự án của bạn và tùy chỉnh nó:

1. Trong Solution Explorer, click chuột phải vào Reports và sau đó click Add->New Item...

2. Chọn Report template.

3. Đặt tên cho report và sau đó click OK

Bước 4 - Chỉnh sửa report

Sau khi bạn đã thêm một báo cáo report vào project, bạn có thể chỉnh sửa nó như sau:

1. Nếu Report Designer không tự động mở, hãy mở report để chỉnh sửa bằng cách click đôi vào nó trong Solution Explorer.

2. Click vào Dataset trong danh sách thả xuống và sau đó chọn <New Dataset...>

3. Đặt tên cho dataset, thí dụ TestDataSet.

4. Chọn TFSOlapReportDS (shared).

5. Click OK.

6. Click the ... button kế bên Build (bên dưới danh sách thả xuống Dataset) và sau đó chọn Team System.

Bây giờ bạn có thể chỉnh sửa báo cáo report bằng cách kéo các kích thước từ cây Dataset tree vào bảng Query Pane và bảng Filter Pane. Bạn có thể chỉnh sửa các layout của report bằng cách click vào thẻ Layout tab. Bạn có thể xem trước report của bạn bằng cách click vào thẻ Preview.

Bước 5 - Triển khai các report đến Team Foundation Server của bạn

Sau khi bạn đã chỉnh sửa report, bạn có thể triển khai nó đến team project's reporting portal của bạn bằng cách thực hiện theo các bước sau:

1. Trong Solution Explorer, click trên report project và sau đó click Properties.

2. Hãy chắc là OverwriteDataSources được gán là false.

3. Hãy chỉnh sửa TargetDataSourceFolder để ánh xạ tên dự án nhóm của bạn; thí dụ:

TargetDataSourceFolder = TestProject.

4. Chỉnh sửa TargetReportFolder để ánh xạ tên dự án nhóm của bạn; thí dụ:

TargetDataSourceFolder = TestProject.

5. Chỉnh sửa TargetDataSourceFolder đến http://<data-tier servername>/reportserver. Thí dụ: TargetDataSourceFolder = http://tfsrtm/reportserver.

6. Click OK.

7. Trong Solution Explorer, click chuột phải lên tập tin rdl và sau đó click Deploy.

8. Xem phần Output Pane để xác nhận hoàn thành thành công.

Bước 6 - Kiểm thử report

Sau khi bạn đã xuất bản báo cáo của bạn đến máy chủ team project's report server bạn có thể kiểm thử nó để chắc là nó được triển khai một cách thành công:

1. Trong Team Explorer hãy mở rộng team project node của bạn, click phải lên Reports và sau đó click Show Report Site

2. Trong trang report site, hãy chọn report mà bạn vừa tạo.

3. Xác nhận là report giống như bạn mong muốn.

Mã nguồn bổ sung

Về các hướng dẫn giải thích thêm làm cách nào để làm việc với các reporting projects, hãy xem "Reporting Services Tutorials" tại http://msdn2.microsoft.com/en-us/library/ms170246.aspx
Để đọc các chủ đề trên Microsoft MSDN® chỉnh sửa các report, hãy xem "How to: Edit Reports in Report Designer" tại http://msdn2.microsoft.com/en-us/library/ms244655(VS.80).aspx
Để có thêm thông tin về các quy tắc bảo mật trên tầng data, hãy xem "Securing Access Through Analysis Services" tại đây http://msdn2.microsoft.com/en-us/library/ms174839.aspx
Để có thêm thông tin về các quy tắc bảo mật trên tầng application, hãy xem "Securing Reporting Services" tại http://msdn2.microsoft.com/en-us/library/ms157198.aspx

Làm thế nào: Tự động chạy Code Analysis với Team Build trong Visual Studio Team Foundation Server

Nguyễn Thị Như Quỳnh — Sun, 21 Feb 2010 20:17:48 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/22/2010 4:17:48 AM

Được áp dụng cho

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)
Microsoft Visual Studio Team System

Tóm tắt

Đề tài Làm thế nào này sẽ dẫn bạn đi qua quá trình cấu hình Team Build gồm có phân tích mã code analysis như là môt bước của quá trình build. Nó sẽ chạy tự động phân tích mã code analysis như một phần của quá trình team build và sẽ báo cáo kết quả của sự phân tích trong các kết quả của quy trình build.

Nội dung

Chủ đề
Xem trước
Tóm tắt các bước
Trước khi bạn bắt đầu
Bước 1 - Kiểm thử Build
Bước 2 - Kích hoạt chế độ Phân Tích Mã Code Analysis cho quá trình Build
Bước 3 - Kiểm thử sự Phân Tích Mã Code Analysis
Mã nguồn bổ sung

Chủ đề

Chạy phân tích mã như một phần của quá trình build để xem xét chất lượng mã.

Xem trước

Visual Studio Team System Team Build cho phép bạn xác định các loại build cho dự án của bạn để cho phép một build server biên dịch ứng dụng của bạn và thực hiện mạng chia sẻ cho nó. Bạn có thể kích hoạt chế độ phân tích mã cho team build để mỗi build được thực hiện phân tích mã và báo cáo kết quả một cách tự động các đến các trang báo cáo kết quả build. Đề tài Làm thế nào này sẽ dẫn bạn đi qua quy trình cấu hình Team Build để phân tích mã như là một bước để build.

Tóm tắt các bước

Bước 1 - Kiểm thử Build
Bước 2 - Kích hoạt chế độ Phân Tích Mã Code Analysis cho quá trình Build
Bước 3 - Kiểm thử sự Phân Tích Mã Code Analysis

Trước khi bắt đầu

Trước khi bạn có thể kích hoạt chế độ phân tích mã cho Team Build, bạn phải đảm bảo là bạn có các yêu cầu cần thiết sau:

• User ID Team Foundation của bạn phải được cho phép để quản lý một build. Hãy yêu cầu nhà quản trị của bạn nếu bạn đảm bảo là các quyền được cho phép của bạn.

Một team build phải có sẵn trong dự án nhóm của bạn. Bạn cũng có thể kiểm tra điều này bằng cách nhìn vào Team Build trong cửa sổ Visual Studio Team Explorer.

Bước 1 - Kiểm thử Build

Bắt đầu bằng kiểm thử team build của bạn để đảm bảo là khong có bất cứ vấn đề gì trước khi kích hoạt chế độ Phân Tích mã. Bạn có thể làm điều này bằng cách theo các bước sau:

1. Trong Visual Studio, hãy mở Team Explorer trong Visual Studio

2. Mở rộng node cho team project của bạn

3. Mở rộng Team Builds node

4. Click chuột lên một team build đã có và sau đó chọn Build Team Project

5. Hãy đảm bảo là quy trình build được thực hiện thành công. Nếu quy trình build bị thất bại hay không thể hoàn thành, hãy sửa các lỗi trước khi chuyển sang bước kế tiếp.

Bước 2 - Kích hoạt chế độ Phân Tích Mã Code Analysis cho quá trình Build

Một khi bạn đả xác nhận là quy trình build đang làm việc tốt, bạn có thể kích hoạt chế độ phân tích code.

Sử dụng các bước sau để kích hoạt chế độ phân tích mã:

1. Hãy mở Source Control Explorer.

2. Trong Source Control Explorer, hãy mở thư mục dự án nhóm của bạn.

3. Mở rộng thư mục TeamBuildTypes folder.

4. Chọn thư mục team build mà bạn muốn kích hoạt chế độ phân tích mã.

5. Check out tập tin TFSBuild.proj từ source control. Bạn có thể cần thực hiện một hoạt động Get Latest Version trên thư mục trước.

6. Trong Source Control Explorer, click đôi vào tập tin TFSBuild.Proj để mở nó ra.

7. Nếu bạn muốn tất cả các dự án đều chạy phân tích mã, bất kể các cài đặt của dự án, hãy thay đổi giá trị thẻ <RunCodeAnalysis> thành Always.

8. Nếu bạn muốn chạy phân tích mã trên từng dự án dựa trên các cài đặt của dự án, hãy thay đổi giá trị thẻ <RunCodeAnalysis> thành Default.

9. Nếu bạn đang sử dụng các thiết lập của từng dự án một và muốn kích hoạt phân tích mã cho một dự án:

a. Mở solution trong Visual Studio.

b. Trong Solution Explorer, click chuột phải lên project.

c. Hãy chọn Properties.

d. Click trên Code Analysis.

e. Hãy chọn Enable Code Analysis check box.

f. Check out tập tin .csproj cho project từ source control.

g. Lưu lại tập tin bằng cách click vào biểu tượng Save trên thanh công cụ toolbar trong khi cửa sổ thuộc tính xuất hiện.

h. Check tập tin .csproj của project lại trong source control.

10. Lưu tập tin TFSBuild.proj và check nó trở lại trong source control.

Bước 3 - Kiểm thử sự Phân Tích Mã Code Analysis

Mỗi lần bạn kích hoạt phân tích mã cho một team build, bạn có thể kiểm thử để chắc là nó làm việc ổn thỏa trơn tru. Sử dụng các bước sau để kiểm thử các Phân tích mã cho quy trình build của bạn:

1. Trong Team Explorer, click chuột phải trên loại build type và sau đó click Build Team Project.

2. Khi quá trình build hoàn thành, hãy click vào đường link đến tập tin build log

3. Bạn nên thấy một số các cảnh báo về Phân tích mã ở cuối tập tin build log. Cảnh báo các IDs sẽ bắt đầu với "CA", như là ví dụ sau:

MSBUILD : warning : CA2209 : Microsoft.Usage : No valid permission requests were found for assembly 'HelloWorldTest'. You should always specify the minimum security permissions using SecurityAction.RequestMinimum.
MSBUILD : warning : CA2210 : Microsoft.Design : Sign 'HelloWorldTest' with a strong name key.
MSBUILD : warning : CA1014 : Microsoft.Design : 'HelloWorldTest' should be marked with CLSCompliantAttribute and its value should be true.

Mã nguồn bổ sung

Để có thêm thông tin về các công cụ phân tích mã, hãy xem "Guidelines for Using Code Analysis Tools" tại đây http://msdn2.microsoft.com/en-us/library/ms182023(VS.80).aspx

• Để có thêm thông tin về các team builds, hãy xem "Overview of Team Foundation Build" tại http://msdn2.microsoft.com/en-us/library/ms181710(VS.80).aspx

Làm thế nào để: Thêm một Lập Trình Viên mới vào Project của bạn trong Visual Studio 2005 Team Foundation Server

Nguyễn Thị Như Quỳnh — Sun, 21 Feb 2010 20:16:48 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/22/2010 4:16:48 AM

Được áp dụng cho

Microsoft® Visual Studio® 2005 Team Foundation Server (TFS)
Microsoft Visual Studio Team System
Microsoft SQL Server^TM Reporting Services

Tóm tắt

Đề tài Làm thế nào này sẽ dẫn bạn đi qua quy trình của việc thêm một nhà phát triển mới vào dự án nhóm của bạn ở trong Team Foundation Server.

Nội dung

Chủ đề
Xem trước
Tổng kết các bước
Bước 1 - Cấp quyền truy cập đến Team Project
Bước 2 - Cấp quyền truy cập đến Microsoft Office SharePoint® project site
Bước 3 - Cấp quyền truy cập đến SQL Server Reporting Services
Mã nguồn bổ sung

Chủ đề

Cho phép một nhà phát triển truy cập đến dự án nhóm
Cấp cho một nhà phát triển quyền truy cập Read và Contributor đến SharePoint
Cho phép một nhà phát triển xem và mô tả các báo cáo

Xem trước

Bất cứ khi nào bạn thêm một nhà phát triển mới vào một dự án, bạn cần cấp cho nhà phát triển đó các quyền phù hợp để truy cập vào dự án nhóm team foundation project và các trang dự án SharePoint liên quan đến nó. Tài khoản của nhà phát triển mới cũng phải có đủ quyền với các dịch vụ SQL Server Reporting Services để có thể xem các báo cáo như là những trình bày của team site portal.

Tổng kết các bước

Bước 1 - Cấp quyền truy cập đến Team Project
Bước 2 - Cấp quyền truy cập đến Microsoft Office SharePoint® project site
Bước 3 - Cấp quyền truy cập đến SQL Server Reporting Services

Bước 1 - Cấp quyền truy cập đến Team Project

Trong bước này bạn cấp cho các thành viên mới của nhóm quyền truy cập đến Team Foundation Server.

Để cấp quyền truy cập đến dự án nhóm:

1. Hãy đăng nhập vào Visual Studio với một tài khoản là một thành viên của nhóm Team Foundation Administrators application group.

2. Thêm dự án được yêu cầu vào Team Explorer (nếu nó có sẵn trong danh sách)

3. Trong Team Explorer hãy click chuột phải vào dự án nhóm, hãy trỏ đến Team Project Settings và click Group Membership.

4. Chọn Project\Contributors và click Properties và sau đó thêm tài khoản của lập trình viên mới vào group này.

Lưu ý là các thành viên trong nhóm Contributors group được cấp tập các quyền cơ bản mà một lập trình viên yêu càu, gồm có khả năng thêm, sửa và xóa các mục trong dự án nhóm và thực hiện các build.

Bước 2 - Cấp quyền truy cập đến Microsoft Office SharePoint® project site

Trong bước này bạn cấp quyền cho các thành viên mới của nhóm truy cập đến trang SharePoint project site.

Đẻ cấp quyền truy cập đến trang SharePoint project site:

1. Truy cập đến trang dự án nhóm với một tài khoản account là thành viên của nhóm SharePoint Administrator site group.

Lưu ý là trang dự án này cho một dự án tên là YourProject được đặt mặc định tại đây http://server/sites/YourProject/default.aspx

2. Click Site Settings.

3. Bên duối tiêu đề Administration , hãy click Manage Users.

4. Click Add Users.

5. Điền tên tài khoản của tài khoản của lập trình viên mới trong form domain\useraccount của developer's account, chọn Contributor và sau đó click Next.

6. Điền địa chỉ e-mail của lập trình viên mới vào trường address field, và tùy chọn một loại tin nhắn để chào mừng khi truy cập vào trang web.

7. Click Finish.

Lưu ý là thành viên đó thuộc về nhóm Contributors group cho phép các lập trình viên xem và thêm nội dung vào thư viện và danh sách các tài liệu đã có. Thành viên trong Reader group, được cấp quyền read only khi truy cập vào trang web, có khả năng phụ thuộc nhiều vào nhu cầu của lập trình viên mới.

Bước 3 - Cấp quyền truy cập đến SQL Server Reporting Services

Trong bước này bạn cấp quyền truy cập cho thành viên mới của nhóm đến SQL Report Services.

Để cấp quyền truy cập đến SQL Server Reporting Services

1. Hãy đăng nhập vào SQL Server Reporting Services administration Web site tại đây http://server/reports bằng cách sử dụng một tài khoản administrator account. .

2. Click vào tên dự án nhóm của bạn.

3. Click vào thẻ Properties tab.

4. Click vào thẻ Security tab.

5. Click New Role Assignment.

6. Điền tên tài khoản Microsoft Windows® của lập trình viên mới, chọn Browser và sau đó click OK.

Lưu ý là thành viên trong nhóm Browser group cho phép các lập trình viên xem và mô tả các báo cáo

Mã nguồn bổ sung

Để có một sự giải thích về làm thế nào để thiết lập các quyền permission trong SQL Server Reporting Services, hãy xem "Setting Permissions in Reporting Services" tại đây http://msdn2.microsoft.com/en-us/library/aa337491.aspx
Để có thêm thông tin về các quy tắc bảo mật security roles trong tầng application, hãy xem "Securing Reporting Services" tại http://msdn2.microsoft.com/en-us/library/ms157198.aspx
Để xem tài liệu hướng dẫn SharePoint Administrators Guide to "Managing Site and Group Permissions", hãy xem http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stsf03.mspx?mfr=true
Để có thêm thông tin về quản lý các quyền permissions trong TFS hãy xem "Managing Permissions" tại đây http://msdn2.microsoft.com/en-us/library/ms253094(VS.80).aspx

Câu hỏi và Trả lời: Team Foundation Server Source Control and Versioning

Nguyễn Thị Như Quỳnh — Sun, 21 Feb 2010 20:09:30 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/22/2010 4:09:30 AM

Bao gồm các phần

Accessing Version Control

• MSSCCI Provider là gì và khi nào nó được sử dụng?

• Các IDE nào khác hỗ trợ TFS?

• Khi nào tôi nên sử dụng công cụ Team Foundation Server Power Tool?

• Các version control thường được sử dụng để mở rộng các kịch bản là gì?

• Làm việc với version control từ command line như thế nào?

Administration

• Làm thế nào để cấp quyền cho một tập tin trong một thư mục có thừa kế các quyền?

• Tôi nên làm gì khi một lập trình viên rởi khỏi dự án?

• Làm thế nào để quản lý các lập trình viên thực tập và những người khác mà không tin tưởng để thực hiện các check-ins?

• Tôi nên chỉnh sửa các permission như thế nào sau khi ứng dụng của tôi đã được trao đi?

Branch/Label/Merge

• Khi nào tôi nên sử dụng các labels?

• Các TFS label khác với các VSS label như thế nào?

• Branching là gì?

• Khi nào tôi nên xem xét phân nhánh branching?

• Lí do gì để không thực hiện phân nhánh branch?

• Sử dụng phân nhánh branching như thế nào để phát hành ứng dụng của tôi?

• Sử dụng branching như thế nào để bảo trì ứng dụng của tôi?

• Sử dụng branching như thế nào để giảm xung đột giữa các teams?

• Sử dụng branching như thế nào để giảm xung đột giữa các chức năng?

• Chứng minh các bài tập về branching và merging là gì?

• Sự khác nhau giữa branching và labeling là gì?

• Mô hình "path space" branching là gì?

• TFS promotion model làm việc như thế nào?

• Tôi sẽ merge hai phân nhánh như thế nào?

• Tôi có thể merge ngang qua các team project không?

• Một baseless merge là gì?

• Code promotion model là gì?

• Các phân nhánh logic và phân nhánh vật lý khác nhau như thế nào?

• Nếu tôi sử dụng code promotion model, thường thì tôi phải merge như thế nào?

Check-ins and Check-in Policies

• Một changeset là gì?

• Một check-in policy là gì?

• Khi nào và tôi có thể override một check-in policy như thế nào?

• Làm cách nào để thực thi một policy?

• Làm thế nào tôi sử dụng một hệ thống kiểm tra các check-in(check-in verification system)?

• Nếu tôi chỉnh sửa tên tập tin hay xóa các tập tin trên ổ đĩa, có phải là version control sẽ bất đồng bộ không?

• Làm thế nào để giải quyết các xung đột một cách tự động?

• Làm thế nào để giải quyết các xung đột bằng tay?

• Làm thế nào để tránh các xung đột?

Checkout, Get, and Lock

• Làm thế nào để tìm ra lập trình viên cuối cùng chỉnh sửa một tập tin?

• Câu lệnh get làm việc như thế nào?

• Sự khác nhau giữa các shared checkout và exclusive checkout?

• Khi nào tôi nên sử dụng lệnh lock command?

• Loại lock nào được TFS hỗ trợ?

Distributed/Remote Development

• Làm thế nào để work offline?

• Làm thế nào để tối ưu hóa việc phân chia phát triển đội ngũ?

• TFS Version Control proxy là gì?

• Làm thế nào để tối ưu hóa năng suất của TFS Version Control proxy?

Migration

• TFS version control khác với VSS như thế nào?

• Mô hình checkout model khác với VSS như thế nào?

• Tôi nên di chuyển source từ VSS đến TFS như thế nào?

• Tôi nên di chuyển source từ version-control system khác như thế nào?

Project/Workspace Management

• Tôi nên tổ chức các team project của tôi như thế nào?

• Tôi nên quản lý các phụ thuộc giữa các project như thế nào?

• Workspace là gì?

• Sử dụng các workspace để cô lập công việc của một nhà phát triển như thế nào?

• Các kiểm chứng thực tiễn đối với workspace mapping là gì?

• Các kiểm chứng thực tiễn đối với quản lý các shared components và code là gì?

• Khi nào tôi nên tạo một team project mới so với một phân nhánh branch mới?

• Tôi nên quản lý source code mà được chia sẻ trên nhiều project như thế nào?

• Tôi nên quản lý các tập tin binary mà được chia sẻ trên nhiều project như thế nào?

• Tôi nên quản lý source tree như thế nào?

Shelving

• Shelving là gì?

• Một Shelveset là gì?

• Khi nào tôi thường sử dụng shelving?

• Tôi sẽ sử dụng shelving để back up công việc của tôi như thế nào?

• Tại sao tôi sẽ muốn unshelve một shelveset?

Accessing Version Control

• MSSCCI Provider là gì và khi nào nó được sử dụng?

• Các IDE nào khác hỗ trợ TFS?

• Khi nào tôi nên sử dụng công cụ Team Foundation Server Power Tool?

• Đâu Là Những Kịch Bản Mở Rộng của các Version Control Phổ Biến/ Thông Thường?

• Làm việc với version control từ command line như thế nào?

MSSCCI Provider Là Gì Và Khi Nào Nó Được Sử Dụng?

The Microsoft® Source Code Control Interface (MSSCCI) provider được sử dụng để cung cấp một version control tích hợp user experience với các sản phẩm không được hỗ trợ Microsoft Visual Studio® Team Explorer. Thí dụ, nếu bạn sử dụng Visual Studio 6.0, thì bạn có thể sử dụng MSSCCI client hay command line để tương tác với Microsoft Visual Studio Team System (VSTS) Team Foundation Version Control.

Các client sau có thể làm việc trực tiếp với Team Foundation Version Control bằng cách sử dụng MSSCCI provider:

Microsoft Visual Studio .NET 2003
Microsoft Visual C++® 6 Service Pack 6 (SP6)
Microsoft Visual Basic® 6.0 SP6
Microsoft Visual FoxPro® 9.0 SP1
Microsoft Access 2003 SP2
Microsoft SQL Server^TM Management Studio
Sparx Systems Enterprise Architect 6.1
Sybase PowerBuilder 105
Toad for SQL Server 2.0

The MSSCCI Provider hoạt động khác với Team Foundation Version Control trong Visual Studio 2005 trong các phương thức sau:

Checkout cũng thực hiện một hành động GetLatest.
Một check-in lock mở rộng được áp dụng khi checkout.
Tùy chọn Open from Source Control và Save to Source Control hoạt động tương tự Microsoft Visual SourceSafe®.

Mã nguồn bổ sung

Để đọc thêm về MSSCCI trên Microsoft MSDN®, hãy xem "The Microsoft Source-Code Control Interface"tại

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcug98/html/_asug_the_microsoft_source_code_control_interface.asp

Để đọc thêm về MSSCCI Provider, hãy xem "Update on the TFS MSSCCI Provider" tại http://blogs.msdn.com/bharry/archive/2006/03/24/559876.aspx
The MSSCCI add-in là một TFS Power Tool đã được phát triển nhưng không được hỗ trợ chính thức từ Microsoft. Để tải công cụ về từ MSDN, hãy đến http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB1E6198&displaylang=en

Các IDE nào khác hỗ trợ TFS?

Team Foundation Server có thể được sử dụng cho bất kì ấn bản nào của Visual Studio 2005 mà có cài Team Explorer . Bạn cũng có thể chạy Team Explorer cùng với bất kì non-Visual Studio 2005 integrated development environment (IDE) để làm việc với các team project và quản lý các work item.

Các client sau có các integration solution được cung cấp bởi các nhà cung cấp khác:

Eclipse
Linux client
Apple Macintosh client
Hypertext Markup Language (HTML) Web client

Nếu bạn muốn truy cập Team Foundation Version Control từ Eclipse IDE, Linux, hay Macintosh clients, hãy cân nhắc việc cài đặt Teamprise suite of client applications, có tại http://www.teamprise.com/

Nếu bạn muốn chỉ là truy cập read-only đến Team Foundation Version Control from the Web, hãy xem xét cài đặt Team System Web Access, có sẵn tại http://msdn2.microsoft.com/en-us/teamsystem/bb676728.aspx

Mã nguồn bổ sung

Để có thêm thông tin về cách sử dụng Team Explorer, hãy xem "Working with Older Visual Studio Projects or Other Code Projects" tại http://msdn2.microsoft.com/en-us/library/ms242912(vs.80).aspx
Để có thêm thông tin về Teamprise, hãy xem http://www.teamprise.com
Để có thêm thông tin về Team System Web Access, hãy xem http://msdn2.microsoft.com/en-us/teamsystem/bb676728.aspx

Khi Nào Tôi Nên Sử Dụng Công Cụ Team Foundation Server Power Tool?

The Team Foundation Power Tool (TFPT) cung cấp các chức năng version-control mà không có sẵn trong Visual Studio 2005 user interface (UI). Thí dụ, bạn có thể sử dung TFPT để hỗ trợ làm việc working offline, hay để thực hiện các hành động rollback để undo check-ins của một changeset. Hãy xem xét sử dụng TFPT nếu bạn cần thực hiện bất kì hành động nào sau đây:

Unshelve - Hoạt động unshelve được hỗ trợ bởi TFS không cho phép shelve các thay đổi change và các thay đổi cục bộ local change được hợp nhất với nhau. Khi bạn sử dụng TFPT để unshelve một thay đổi từ một changeset, nếu một item trong local workspace của bạn có một pending change là một edit, và shelved change cũng là một edit, thì sau đó TFPT có thể merge các change bằng cách thực hiện một merge 3 cách.
Roll back - Khả năng undo một check-in của một changeset không được hỗ trợ trực tiếp trong TFS. Bằng cách sử dụng lệnh TFPT rollback, bạn có thể thực hiện undo bất kì change nào được tạo ra trong một changeset cụ thể. Không phải tất cả các thay đổi change đều có thể roll back, nhưng hầu như có thể rollback cho hầu hết các tình huống.
Work offline - Công cụ TFPT online tool cho phép bạn làm việc mà không kết nối với server trong một khoảng thời gian bằng cách cung cấp các chức năng thông báo cho server về các thay đổi changes mà bạn đã tạo ra trong không gian làm việc cục bộ workspace của bạn.
Get a changeset - Lệnh TFPT GetCS cho phép bạn lấy tất cả các item được liệt kê trong một changeset dựa trên các changeset version. Điều này sẽ có ích nếu một đồng nghiệp check in một thay đổi change mà bạn cần có trong workspace của bạn, nhưng bạn không thể cập nhật toàn bộ workspace lên version mới nhất.
Remove pending edits - Lệnh TFPT UU (Undo Unchanged) xóa bỏ các pending edits từ các files chưa thực sự được chỉnh sửa. Điều này hữu ích trong một tình huống mà bạn check out một số lượng lớn các file để chỉnh sửa, nhưng chỉ làm thay đổi một số ít các tập tin. Bạn có thể lấy ra các chỉnh sửa của bạn trên các tập tin không thể thay đổi bằng cách chạy lệnh TFPT UU, lệnh này sẽ so sánh các dữ liệu hỏng hash của các tập tin trên workspace cục bộ với các tập tin hỏng hash trên server để xác định xem là các tập tin đó có thực sự được chỉnh sửa hay không

Bạn có thể chạy từng lệnh này từ cửa sổ dòng lệnh bằng cách sử dụng Tfpt.exe.

Mã nguồn bổ sung

Để download TFPT, hãy đến

http://www.microsoft.com/downloads/details.aspx?FamilyID=7324c3db-658d-441b-8522-689c557d0a79&DisplayLang=en

Để xem một forum thảo luận về TFPT, hãy đến http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1

Đâu Là Những Kịch Bản Mở Rộng của các Version Control Phổ Biến/ Thông Thường?

Những kịch bản mở rộng của các version control phổ biến là tùy chỉnh một chính sách check-in policy để thực thi các tiêu chuẩn vào lúc check-in. Để tạo các custom policy plug-in mà xuất hiện trong hộp thoại Add Checkin Policy , hãy sử dụng các chức năng mở rộng được cung cấp trong Visual Studio Team Foundation Server Software Development Kit (SDK). Bạn có thể tải TFS SDK về từ http://go.microsoft.com/fwlink/?linkid=68586

Mặc dù không phải là phổ biến, nó cho phép viết một layer tích hợp để cho phép một client không phải là Visual Studio 2005 làm việc với Team Foundation Version Control.

Mã nguồn bổ sung

Để tìm hiểu làm thế nào tùy chỉnh một check-in policy, hãy xem "Walkthrough: Customizing Check-in Policies and Notes" tại đây http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx
Để xem các đoạn code đơn giản mà không cho phép chọn các mẫu trên check-in, hãy xem "Checkin Policy to Disallow Certain Patterns" tại http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx

• Để xem các đoạn code đơn giản buộc phải comments các check-in, hãy xem "Sample Checkin Policy: Make Sure the Comment Isn't Empty" tại http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx

Để tìm hiểu làm thế nào đăng kí một check-in policy mới, hãy xem "I've Made a New Check-In Policy! How Do I Add It?" tại http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx
Để download the TFS SDK, hãy đến http://go.microsoft.com/fwlink/?linkid=68586
Để tìm hiểu thêm về Team Foundation Version Control extensibility, hãy xem "Walkthru: The Version Control Object Model" tại http://msdn2.microsoft.com/en-us/library/bb187335(VS.80).aspx

Làm Việc Với Version Control Từ Command Line Như Thế Nào?

Team Foundation Server cung cấp công cụ TF command line tool (Tf.exe) để cho phép bạn thực hiện các hoạt động source control. Thí dụ, bạn có thể sử dụng dòng lệnh để lên kế hoạch cho các hoạt động bằng cách sử dụng Microsoft Windows® Task Scheduler.

Để đảm bảo là các đường dẫn phù hợp và các môi trường khác được thiết lập, bạn hãy chạy công cụ từ Visual Studio 2005 Command Prompt window, hay là chạy tập tin Vsvars32 batch file, thường được đặt trong DriveLetter:\Program Files\Microsoft Visual Studio 8\Common7\Tools. The command line hỗ trợ hầu hết các lệnh source control, gồm có Checkin, Checkout, Get, History, Shelve, Branch, Merge, Label, Status, Undelete, và Undo.

Sau đây là các hoạt động thông thường mà bạn có thể muốn thực thi từ command line:

Đồng bộ các tập tin từ server đến máy tính của bạn - tf get
Thêm một tập tin đến server - tf add
Check out một tập tin để chỉnh sửa - tf checkout
Check in các thay đổi đang chờ xử lý pending changes - tf checkin
Retrieve một tập changeset cụ thể từ server - tf get /version

Các hoạt động sau chỉ có thể được thực thi từ command line:

Xóa workspace của một user - tf workspace /delete
Undo lại check-in của một user - tf undo
Unlock lại các lock của một user - tf lock
Xác định label scope - tf label
Thực hiện một baseless merge - tf merge

Mã nguồn bổ sung

Để có thêm thông tin về làm việc với các lệnh Tf.exe commands, hãy xem "MSDN: Walkthrough: Working with Team Foundation Source Control from Command Line" tại http://msdn2.microsoft.com/en-us/library/zthc5x3f.aspx
Để có thêm thông tin về các lệnh có sẵn từ command line, hãy xem "Operations Available Only From the Command-Line (Team Foundation Source Control)" tại http://msdn2.microsoft.com/en-us/library/ms194957(VS.80).aspx

Tài liệu hoàn chỉnh của phần này bạn có thể download tại đây:

http://cid-c756261140cf0eb3.skydrive.live.com/self.aspx/GT/Cau%20hoi%20va%20Tra%20loi.doc

Bài tập : Source Control

Nguyễn Thị Như Quỳnh — Sun, 21 Feb 2010 19:59:52 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/22/2010 3:59:52 AM

Các mục

Accessing Version Control

• Làm thế nào để sử dụng các phiên bản version control từ các client không có Visual Studio

• Làm thế nào để tự động hóa các task của version-control chung

• Làm thế nào để work offline

Administration

• Làm thế nào để thêm một lập trình viên mới vào dự án của bạn

• Làm thế nào để loại bỏ đi một lập trình viên sẽ rời khỏi dự án của bạn

• Làm thế nào để cấp quyền trong source tree của bạn

• Làm thế nào để si chuyển Team Foundation Server Version Control của bạn đến server khác

Branch/Label/Merge

• Làm thế nào để sử dụng các label

• Làm thế nào để branch

• Làm thế nào để lên kế hoạch cho cấu trúc branch của bạn

• Làm thế nào để sử dụng branching để hỗ trợ một release

• Làm thế nào để sử dụng branching để bảo trì một previous release

• Làm thế nào để sử dụng branching để ổn định sự phát triển của bạn và build process

• Làm thế nào để sử dụng branching để ổn định các chức năng phát triển của bạn

• Làm thế nào để sử dụng branching để ổn định sự phát triển giữa các nhóm

• Làm thế nào để sử dụng branching để tách riêng các phụ thuộc mở rộng

• Làm thế nào để bỏ một phiên bản(release) cũ

• Làm thế nào để thực hiện một sự hợp nhất merge

• Làm thế nào để thực hiện một baseless merge

• Làm thế nào để giả quyết xung đột trong khi hợp nhất(merge conflicts )

Builds

• Làm thế nào để sử dụng TFS để thực thi các Continuous Integration builds

Check-ins and Check-in Policies

• Làm thế nào để làm việc với các tập thay đổi trong source control

• Làm thế nào để thực thi các tiêu chuẩn về mã trước khi check-in

• Làm thế nào để ghi đè một check-in policy

• Làm thế nào để khôi phục một check-in

• Làm thế nào để giải quyết một xung đột

• Làm thế nào để tránh các xung đột

• Làm thế nào để tạo một check-in policy tùy ý bạn về Checkout, Get, and Lock

• Làm thế nào để đồng bộ hóa máy tính của bạn với TFS

• Làm thế nào để chuẩn bị một file để chỉnh sửa

Checkout, Get, and Lock

• Làm thế nào để đồng bộ máy tính của bạn với TFS

• Làm thế nào để chuẩn bị một tập tin để chỉnh sửa

Code Sharing

• Làm thế nào để share code

• Làm thế nào để quản lý các tập tin nhị phân chia sẻ shared binaries

Dependencies

• Làm thế nào để quản lý các Web service dependencies

• Làm thế nào để quản lý các database dependencies

Distributed/Remote Development

• Làm thế nào để truy cập đến TFS qua Internet

• Làm thế nào để tối ưu hóa năng suất TFS Version Control proxy performance

Migration

• Làm thế nào để di chuyển source của bạn từ Visual SourceSafe

• Làm thế nào để di chuyển source của bạn từ các version-control system khác

Project/Workspace Management

• Làm thế nào để chọn một team project trong nhiều team projects

• Làm thế nào để tổ chức source tree của bạn

• Làm thế nào để xác định các workspace mappings

• Làm thế nào để sử dụng các workspace để tách riêng các code change trên máy của bạn

Security

• Làm thế nào để secure the channel between a developer workstation and TFS

Shelving

• Làm thế nào để sử dụng shelving để back up các pending work

• Làm thế nào để sử dụng shelving để share code với một team member

Accessing Version Control

• Làm thế nào để sử dụng các phiên bản version control từ các client không có Visual Studio

• Làm thế nào để tự động hóa các task của version-control chung

• Làm thế nào để work offline

Làm Thế Nào Để Sử Dụng Các Phiên Bản Version Control Từ Các Client Không Có Visual Studio

Bạn có thể truy cập đến Microsoft® Visual Studio® 2005 Team System (VSTS) Team Foundation Server (TFS) Version Control từ các client khác bằng cách sử dụng một trong các phương thức tiếp cận sau:

Microsoft Source Code Control Interface (MSSCCI) integration
Third-party integration
Custom integration

MSSCCI Integration

Các client sau có thể làm việc trực tiếp với TFS Version Control bằng cách sử dụng MSSCCI provider:

Microsoft Visual Studio .NET 2003
Microsoft Visual C++® 6 SP6
Microsoft Visual Basic® 6 SP6
Microsoft Visual FoxPro® 9 SP1
Microsoft Access^TM 2003 SP2
Microsoft SQL Server^TM Management Studio
Sparx Systems Enterprise Architect 61
Sybase PowerBuilder 105
Toad for SQL Server 2.0

MSSCCI provider vận hành khác với TFS Version Control trong Visual Studio 2005 theo các cách thức sau:

Checkout cũng thực hiện một hành động GetLatest .
Một check-in lock dành riêng được áp dụng tại lúc checkout.
Open từ source control và save vào source control hoạt động giống như trong Microsoft Visual SourceSafe® (VSS).

Bạn có thể tải MSSCCI provider từ Microsoft MSDN® tại đây

http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB1E6198&displaylang=en

MSSCCI provider không được Microsoft hỗ trợ. Nếu bạn có câu hỏi, hãy tham khảo ý kiến tại MSDN forums ở đây

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=22&SiteID=1

Third-Party Integration

Các client sau có các intergration solutions được cung cấp bởi các nhà cung cấp khác:

Eclipse
Linux client
Apple Macintosh client
HTML Web client

Nếu bạn muốn truy cập đến các TFS Version Control từ các client Eclipse IDE, Linux, hay Macintosh , hãy xem xét việc cài đặt Teamprise từ http://www.teamprise.com/

Nếu bạn chỉ muốn truy cập với quyền read-only đến TFS Version Control từ Internet, hãy xem xét sử dụng Team System Web Access từ http://msdn2.microsoft.com/en-us/teamsystem/bb676728.aspx

Custom Integration

Các client khác hiện không có sẵn các integration solution. Bạn có thể truy cập đến TFS Version Control cả từ command line hay build các integration solution của riêng bạn.

Để tìm hiểu thêm về làm việc với TFS Version Control, hãy xem "Walkthrough: Working with Team Foundation Source Control from Command Line" trên trang MSDN Web site ở đây http://msdn2.microsoft.com/en-us/library/zthc5x3f(VS.80).aspx

Bạn có thể sử dụng các script điều khiển và các command file dể tự động hóa việc sử dụng của các dòng lệnh.

Để tìm hiểu thêm về cách làm việc với các script điều khiển và các command file, hãy xem "Team Foundation Source Control Scripts and Command Files" trên trang MSDN Web site tại đây http://msdn2.microsoft.com/en-us/library/1az5ay5c(VS80).aspx

Mã nguồn bổ sung

Để download the MSSCCI provider từ MSDN, hãy đến

http://www.microsoft.com/downloads/details.aspx?FamilyId=87E1FFBD-A484-4C3A-8776-D560AB1E6198&displaylang=en

Nếu bạn muốn truy cập đến TFS Version Control từ các Eclipse IDE, Linux, hay Macintosh clients, hãy cân nhắc đến việc cài đặt Teamprise ở trang http://www.teamprise.com/
Nếu bạn muốn truy cập đến TFS Version Control từ Internet, hãy cân nhắc đến việc cài đặt Team System Web Access ở đây http://msdn2.microsoft.com/en-us/teamsystem/bb676728.aspx
Để tìm hiểu thêm về cách làm việc TFS Version Control, hãy xem "Walkthrough: Working with Team Foundation Source Control from Command Line" tại đây http://msdn2.microsoft.com/en-us/library/zthc5x3f(VS.80).aspx
Để tìm hiểu thêm về cách làm việc control scripts và command files, hãy xem "Team Foundation Source Control Scripts and Command Files" tại đây http://msdn2.microsoft.com/en-us/library/1az5ay5c(VS80).aspx
Để tìm hiểu thêm về cách làm việc TFS Version Control extensibility, hãy xem "Walkthrough: The Version Control Object Model" tại đây http://msdn2.microsoft.com/en-us/library/bb187335(VS.80).aspx

Làm Thế Nào Để Tự Động Hóa Các Task Của Version-Control Chung

Để tự động hóa các version-control task chung, hãy sử dụng công cụ dòng lệnh của Team Foundation (tf.exe). Với công cụ này, bạn có thể làm tất cả mọi thứ mà bạn có thể làm việc với Source Control Explorer, gồm có các hành động trong source control (add, check-in, checkout, get, lock, label, và nhiều hơn), branching, shelving, workspace manipulation, và tạo ra các administration task.

Lý do chính để sử dụng công cụ dòng lệnh là tự động hoá các hoạt động lặp đi lặp lại là lên lịch các hoạt động để chạy tại các thời điểm cụ thể hay trên các sự kiện cụ thể bằng cách sử dụng Microsoft Windows® Task Scheduler. Các lệnh sau cũng có sẵn từ dòng lệnh:

Delete các workspace của các user khác
Undo các checkout của các user khác
Unlock các lock của các user khác
Xác định phạm vi của các label
Thực hiện một baseless merge

Để đảm bảo là các đường dẫn phù hợp và các biến môi trường được cài đặt, hãy chọn công cụ dòng lệnh từ cửa sổ Visual Studio 2005 Command Prompt window, hay chạy Vsvars32 batch file, là tập tin được đặt trong DriveLetter:\Program Files\Microsoft Visual Studio 8\Common7\Tools.

Tf.exe được cài đặt như một phần của TFS client và được đặt mặc định trong thư mục sau: C:\Program Files\Microsoft Visual Studio 8\Common 7\IDE.

Để chạy công cụ dòng lệnh, bạn phải xác định tên vớ /s switch. Dòng lệnh sau hiển thị bằng cách nào để xem các tập tin trong source control trên server có tên là YourTFSServer:

tf.exe dir /s:YourTFSServer

Mã nguồn bổ sung

Để có thêm thông tin, hãy xem "Walkthrough: Working with Team Foundation Source Control from Command Line" trên trang MSDN Web site tại đây http://msdn2.microsoft.com/en-us/library/zthc5x3f(VS.80).aspx
Để có thêm thông tin, hãy xem "MSDN Team Foundation Source Control Command-Line Reference" tại đây http://msdn2.microsoft.com/en-us/library/cc31bk2e(VS.80).aspx

Làm Thế Nào Để Work Offline

Offline working không được hỗ trợ mặc định trong TFS Version Control.

Để work offline, bạn cần sử dụng nghiêm ngặt các quy trình workflow sau:

1. Remove bằng tay các cờ đánh dấu read-only. Mặc định, tất cả các tập tin trong workspace không được check out được đánh dấu là read-only. Khi bạn làm việc mà không kết nối với một server, bạn phải remove bằng tay các cờ đánh dấu read-only từ các tập tin trước khi chỉnh sửa hay là xóa chúng. Để thực hiện điều này, hãy click phải lên tập in trong Windows Explorer, click Properties, xóa dấu chọn Read-only check box, và sau đó click OK. Ngoài ra, bạn có thể sử dụng DOS command attrib -r

2. Chỉnh sửa các tập tin. Bạn bây giờ có thể chỉnh sửa bất cứ tập tin nào mà bạn đã remove các cờ đánh dấu read-only.

3. Thêm hoặc chỉnh sửa các tập tin. Bạn có thể thêm hay xóa các tập tin mà bạn đã remove các cờ đánh dấu read-only. Đừng rename file, bởi vì công cụ TFPT online tool không thể phân biệt một hành động rename từ một cặp hành động xóa với một hành động thêm.

Lưu ý: Bạn phải xác định một tùy chọn đến TFPT online command để lấy nó để tìm kiếm các sự xóa bỏ vì đây là một hành động tốn thời gian hơn.

4. Chạy TFPT online command. Khi bạn online trở lại, hãy chạy TFPT online command bằng cách đánh chữ TFPT online bằng dòng lệnh. Lệnh này sẽ quét workspace của bạn đối với các tập tin ghi được và xác định những thay đổi nào cần được pended trên server. Nếu bạn đã xóa bất kì một tập tin nào, hãy sử dụng /delete switch. Nó sẽ nói cho công cụ này biết là để quét đối với các tập tin bị xóa trong workspace của bạn. Sau đó công cụ này sẽ hiển thị cửa sổ online window mà bạn có thể chọn các thay đổi để được pend vào workspace.

Quan trọng: Bạn không nên rename bất kì tập tin nào trong khi bạn offline.

Mã nguồn bổ sung

Để download công cụ TFPT tool từ MSDN, hãy đến

http://www.microsoft.com/downloads/details.aspx?FamilyID=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en

Để tìm hiểu về công cụ Visual Studio Team Foundation Power Tool, hãy xem "Power Toy: tfptexe" tại http://blogs.msdn.com/buckh/archive/2005/11/16/493401.aspx

Tài liệu hoàn chỉnh của phần này các bạn có thể download tại đây:

http://cid-c756261140cf0eb3.skydrive.live.com/self.aspx/GT/Source%20Control.doc

Bài tập : Reporting

Nguyễn Thị Như Quỳnh — Sun, 31 Jan 2010 17:52:47 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/1/2010 1:52:47 AM

Các mục

Administration

• Làm sao để cài đặt một report dashboard

• Làm sao để thiết lập các permission trên các report

Creation / Customization

• Làm sao để tùy chỉnh một report đã có

• Làm sao để tạo một report mới trong Visual Studio

• Làm sao để tạo một report mới trong Excel

• Làm sao để tạo một scheduled report snapshot

• Làm sao để tạo một report subscription

• Làm sao để thêm một report mới đến một process template đã có

Viewing

• Làm thế nào để phân tích tình trạng của một dự án

• Làm thế nào để phân tích chất lượng của ứng dụng

• Làm thế nào để xem các công việc còn lại

• Làm thế nào để xem tình trạng build

• Làm thế nào để xem các bug và các kết quả kiểm thử

• Làm thế nào để xem các công việc theo lịch trình so với công việc thực tế trên một iteration

• Làm thế nào để xác định người chỉnh sửa cuối cùng của một tập tin

• Làm thế nào để phát hiện tất cả các sự thay đổi code được thực hiện bởi một lập trình viên

• Làm thế nào để phát hiện tất cả các thay đổi của code được thực hiện cho một tập tin

• Làm thế nào để phát hiện tất cả các thay đổi của code liên quan đến một work item cụ thể

• Làm thế nào để tạo các code churn metrics

• Làm thế nào để tạo các workspace metrics như là số lượng các tập tin, số dòng mã, và số dự án

Administration

• Làm sao để cài đặt một report dashboard

• Làm sao để thiết lập các permission trên các report

Làm thế nào để Cài đặt một Report Dashboard

Chỉnh sửa trang team project portal Microsoft Office SharePoint® site dể tạo một report dashboard mà có thể cung cấp nhiều thông tin dự án tại một vị trí.

Thí dụ, một reporting dashboard hữu ích có thể chứa các report sau:

Remaining Work
Quality Indicators
Bug Rates
Project Velocity

Bạn có thể thêm mới các report đến trang SharePoint portal của bạn bằng cách thêm một Report Viewer Web Part cho từng report mà bạn muốn hiển thị trên trang đó.

Để chỉnh sửa team project portal và tạo một reporting dashboard

1. Cài đặt Report Viewer Web part trên report server của bạn bằng cách sử dụng công cụ stsadm.exe tool và RSWebParts.cab, gồm có Microsoft Office SharePoint và Report Services installation package.

o STSADM.EXE có thể được tìm thấy theo đường dẫn sau: C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN

o RSWebParts.Cab có thể được tìm thấy theo đường dẫn sau: C:\ Program

Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint

Example: STSADM.EXE -o addwppack -filename "C:\ Program

Files\Microsoft SQL Server\90\Tools\Reporting

Services\SharePoint\RSWebParts.cab" -globalinstall

2. Trong Team Explorer, click phải trên dự án của bạn và sau đó click Show Project Portal.

3. Click Modify Shared Page, trỏ đến Browse, và sau đó click Add Web Parts.

4. Click Virtual Server Gallery.

5. Từ Web Part List, hãy chọn Report Viewer.

6. Click Add.

7. Nhập tên Report Manager name, như là http://<report server>/reports.

8. Nhập đường dẫn cho dự án mà bạn muốn hiển thị, như là <my project>/Quality Indicators.

Mã nguồn bổ sung

Để có thêm thông tin về thêm một Report Viewer Web Part, hãy xem "Viewing Reports with SharePoint 2.0 Web Parts" tại http://msdn2.microsoft.com/en-us/library/ms159772(SQL.90).aspx
Để có thêm thông tin về team project portal, hãy xem "Using the Team Project Portal" tại http://msdn2.microsoft.com/en-us/library/ms242883(VS.80).aspx

Làm Sao Để Thiết Lập Các Permission Trên Các Report

Bạn có thể chỉnh sửa các report permissions để xác định ai có thể chỉnh sửa và xem các report. Bạn phải là một thành viên của Microsoft SQL Server^TM Reporting Services Content Manager role để có thể được thiết lập các report permissions.

Để thiết lập các permissions cho tất cả các report trong team project của bạn

1. Trong Team Explorer, hãy mở rộng node của team project của bạn.

2. Click phải lên Reports và sau đó click Show Report Site.

3. Click the Properties tab.

4. Click Security.

5. Click Edit Item Security.

6. Nếu bạn muốn chỉnh sửa security trên một role đã được xác định trước cho report, hãy click Edit.

7. Nếu bạn muốn xác định security cho một role mà không được liệt kê ra, hãy click New Role Assignment.

Để thiết lập các permissions trên một single report

1. Trong Team Explorer, hãy mở rộng node của team project của bạn.

2. Click phải lên Reports và sau đó click Show Report Site.

3. Trên trang report site, hãy chọn report mà bạn muốn thiết lập các permission.

4. Click vào Properties tab.

5. Click Security.

6. Click Edit Item Security.

7. Nếu bạn muốn chỉnh sửa security trên một role mà đã được xác định cho một report, hãy click Edit.

8. Nếu bạn muốn xác định security cho một role mà không được liệt kê ra, hãy click New Role Assignment.

Mã nguồn bổ sung

Để có thêm thông tin về thiết lập các report permissions, hãy xem "How to: Set Permissions for a Report" tại đây http://msdn2.microsoft.com/en-us/library/ms181645(VS.80).aspx

Creation / Customization

• Làm sao để tùy chỉnh một report đã có

• Làm sao để tạo một report mới trong Visual Studio

• Làm sao để tạo một report mới trong Excel

• Làm sao để tạo một scheduled report snapshot

• Làm sao để tạo một report subscription

• Làm sao để thêm một report mới đến một process template đã có

Làm Sao Để Tùy Chỉnh Một Report Đã Có

Bạn có thể chỉnh sửa các report bằng cách sử dụng SQL Server 2005 Reporting Services Designer bên trong Visual Studio (Business Intelligence Development Studio), cò cả các công cụ SQL Server 2005 client. Chỉnh sửa một report có sẵn thường dễ hơn là tạo một report mới.

Để tùy chỉnh một report đã có trong TFS

1. Tạo một reporting project như sau:

a. Trong Visual Studio, click File, click New, và sau đó click Project.

b. Chọn loại Business Intelligence Project type.

c. Chọn mẫu là Report Server Project template.

d. Điền tên và chọn vị trí vào phần Name và Location và sau đó click OK.

2. Export báo cáo report mà bạn muốn tùy chỉnh như sau:

a. Click phải lên team project của bạn và sau đó click Show Project Portal.

b. Trong thanh Quick Launch ở phần bên trái của portal Web site, click Reports.

c. Click vào report mà bạn muốn tùy chỉnh.

d. Click Properties.

e. Hãy chọn Edit.

f. Lưu tập tin report .rdl trong thư mục reporting project mà bạn đã tạo trong bước 1.

3. Thêm các data sources như sau:

a. Để tạo kho warehouse data source:

i. Trong Visual Studio Solution Explorer, click phải Shared Data Sources và sau đó click Add New Data Source.

ii. Trên thẻ General tab, trong ô Name text box, hãy điềnTfsReportDS

iii. Trong Type combo box, hãy chọn Microsoft SQL Server.

iv. Click Edit.

v. Điền tên server tầng data của bạn.

vi. Chọn TFSWarehouse database.

vii. Click vào nút OK hai lần để thêm data source.

b. Để tạo OLAP data source:

i. Trong Solution Explorer, click phải Shared Data Sources và sau đó click Add New Data Source.

ii. Trên thẻ General tab, trong ô Name text box,nhập tên như sau TfsOlapReportDS

iii. Trong Type combo box, chọn Microsoft SQL Server Analysis Services.

iv. Click Edit.

v. Điền tên server tầng data của bạn.

vi. Chọn TFSWarehouse database.

vii. Click vào nút OK hai lần để thêm data source.

4. Thêm report vừa tạo vào project của bạn như sau:

a. Trong Solution Explorer, click phải lên Reports và sau đó click

Add ->Existing Item.

b. Browse đến tập tin rdl mà bạn đã export trong bước 2.

5. Chỉnh sửa report như sau:

a. Chỉnh sửa các câu lệnh truy vấn trong Data Pane.

b. Kéo các số liệu hoặc các thành phần vào Data Pane.

c. Chỉnh sửa report layout trong Layout Pane.

Lưu ý: Mặc dù bạn có thể sử dụng Report Builder có sẵn trong trang team reporting site, nhưng công cụ này không hỗ trợ tốt cho các Visual Studio reporting scenarios và vì vậy mà không được khuyến khích sử dụng.

Mã nguồn bổ sung

Để có thêm thông tin, hay xem "How To - Customize a Report in Visual Studio Team Foundation Server" trong tài liệu.

Làm Sao Để Tạo Một Report Mới Trong Visual Studio

Bạn có thể tạo các report bằng cách sử dụng SQL Server 2005 Reporting Services Designer ở trong Visual Studio (Business Intelligence Development Studio), cùng với các công cụ SQL Server 2005 client.

Tạo một report mới nếu không có sẵn một report nào có thể chỉnh sửa để đáp ứng cho nhu cầu của bạn. Chỉnh sửa một report đã có thường dễ hơn là tạo một report mới.

Để tạo một report mới trong TFS

1. Tạo một reporting project như sau:

a. Trong Visual Studio, click File, click New, và sau đó click Project.

b. Chọn loại Business Intelligence Project type.

c. Chọn mẫu là Report Server Project template.

d. Điền tên và chọn vị trí vào phần Name và Location và sau đó click OK.

2. Thêm các data sources như sau:

a. Để tạo kho warehouse data source:

i. Trong Visual Studio Solution Explorer, click phải Shared Data Sources và sau đó click Add New Data Source.

ii. Trên thẻ General tab, trong ô Name text box, hãy điềnTfsReportDS

iii. Trong Type combo box, hãy chọn Microsoft SQL Server.

iv. Click Edit.

v. Điền tên server tầng data của bạn.

vi. Chọn TFSWarehouse database.

vii. Click vào nút OK hai lần để thêm data source.

b. Để tạo OLAP data source:

i. Trong Solution Explorer, click phải Shared Data Sources và sau đó click Add New Data Source.

ii. Trên thẻ General tab, trong ô Name text box,nhập tên như sau TfsOlapReportDS

iii. Trong Type combo box, chọn Microsoft SQL Server Analysis Services.

iv. Click Edit.

v. Điền tên server tầng data của bạn.

vi. Chọn TFSWarehouse database.

vii. Click vào nút OK hai lần để thêm data source.

3. Tạo một report mới như sau:

a. Trong Solution Explorer, click phải vào Reports, trỏ đến Add, và sau đó click New Item.

b. Hãy chọn template cho Report.

c. Đặt tên cho report và sau đó click OK.

4. Chỉnh sửa report như sau:

a. Nếu Report Designer không tự động mở ra, hãy mở report để chỉnh sửa bằng cách click đôi vào nó trong Solution Explorer.

b. Trong danh sách Dataset drop-down list, hãy chọn <New Dataset...>.

c. Đặt tên cho dataset; thí dụ TestDataSet.

d. Chọn TFSOlapReportDS (shared).

e. Click OK.

f. Click vào nút ellipsis (...) button kế bên Build (ở bên dưới danh sách Dataset drop-down list), và sau đó chọn Team System.

Bây giờ bạn có thể chỉnh sửa report của bạn bằng cách thay đổi kéo các số liệu và các kích cỡ (measures and dimensions) từ cây Dataset tree vào Query Pane và Filter Pane. Bạn có thể chỉnh sửa layout của report bằng cách click vào thẻ Layout tab. Bạn có thể xem trước report của bạn bằng cách click vào thẻ Preview tab.

Lưu ý: Mặc dù bạn có thể sử dụng Report Builder có sẵn từ trang team reporting site, nhưng công cụ này không được hỗ trợ tốt cho các Visual Studio reporting scenarios và vì thế nên không được khuyến khích sử dụng.

Mã nguồn bổ sung

Để có thêm thông tin, hãy xem "How To - Create a Custom Report for Visual Studio Team Foundation Server" trong tài liệu này.

Làm Thế Nào Để Tạo Mới Một Report Trong Excel

Bạn có thể các report phù hợp bằng cách kết nối Microsoft Office Excel® trực tiếp đến TFS Reporting OLAP cube. Bằng cách sử dụng Excel, bạn có thể hiển thị report data trong form của pivot tables hay các pivot chart.

Để tạo một Excel pivot table report

1. Hãy đảm bảo là bạn đã cài đặt Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB Provider. Bạn có thể cài đặt nó từ http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc

2. Khởi động Excel.

3. Hãy chọn worksheet mà bạn muốn để thêm các pivot table report.

4. Ở trên Data menu, hãy chọn PivotTable và PivotChart Report.

5. Hãy chọn External Data Source.

6. Click Next.

7. Click Get Data.

8. Click vào thẻ OLAP Cubes tab.

9. Chọn <New Data Source> và sau đó click OK.

10. Đặt một tên cho data source.

11. Hãy chọn Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB provider.

12. Click Connect.

13. Chọn Analysis Server.

14. Điền tên của reporting server của bạn; thí dụ, TFSRTM.

15. Click Next.

16. Chọn TFSWarehouse và sau đó click Finish.

17. Chọn cube mà bạn muốn build một report (ví dụ, Code Churn, Work Items, và Test Result) và sau đó click OK.

18. Click OK againmột lần nữa để trở về Pivot Table và Pivot Chart Wizard.

19. Click Finish để thêm pivot table vào worksheet.

Sử dụng PivotTable Field List để kéo và thả các column và các measure vào pivot table. Thí dụ, để xem một line count cho từng Team Project trên server của bạn:

1. Chọn Code Churn cube trong bước 17 ở trên.

2. Kéo TeamProject.TeamProject vào phần Column Fields của pivot table.

3. Kéo Total Lines vào phần Data Items của pivot table.

Mã nguồn bổ sung

Để có thêm thông tin về sử dụng Excel để tạo các report thích hợp, hãy xem "Using Microsoft Excel for Team Foundation Server Reporting" tại

http://msdn2.microsoft.com/en-us/library/ms244713(VS.80).aspx

Cài đặt Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB Provider từ đây

http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc

Làm thế nào để Tạo một Scheduled Report Snapshot

Bạn có thể sử dụng scheduled report snapshots để hiểu rõ hơn các xu hướng theo thời gian, hay để nhớ các mốc dữ liệu quan trọng thông qua duration của project của bạn.

Để tạo một scheduled report snapshot

1. Trong Team Explorer, click phải lên Reports đối với team project của bạn và sau đó click Show Report Site.

2. Mở một report từ trang report site.

3. Click thẻ Properties tab.

4. Click vào History link.

5. Cài đặt một schedule khi mà bạn muốn chạy snapshot.

Sau khi schedule được cài đặt, bạn có thể tìm các snapshot trên thẻ History cho report đó. Bạn cũng có thể tạo các snapshot bằng tay trên thẻ History tab.

Làm thế nào để Tạo một Report Subscription

Bạn có thể sử dụng các report subscriptions để tạo các reports và export chúng thành một tạp tin để chia sẻ cho các người khác sử dụng. Bạn có thể cài đặt các subscription để ghi đè lên các report cũ, hay bạn có thể build một tạp các report theo thời gian để xem các snapshot của dữ liệu của dự án.

Để tạo một report subscription

1. Trong Team Explorer, click phải lên Reports đối với team project của bạn và sau đó click Show Report Site.

2. Mở một report từ trang report site.

3. Click vào thẻ Subscriptions tab.

4. Click New Subscription để tạo report subscription.

Làm thế nào để Thêm một Report Mới cho một Process Template đã có

Bạn có thể sử dụng công cụ Process Editor tool, có sẵn trong phiên bản mới nhất của Team Foundation Server Power Tool, để thêm một report mới cho một process template đã có. Bạn có thể tại công cụ Team Foundation Server Power Tool từ đây http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx

Để thêm các report mới

1. Tải process template mà phù hợp với các yêu cầu của bạn nhất như sau:

a. Trong Visual Studio, click Team và sau đó chọn Team Foundation Server Settings.

b. Click Process Template Manager.

c. Trong hộp thoại Process Template Manager dialog box, hãy chọn process template mà bạn muốn chỉnh sửa và sau đó click Download.

d. Trong hộp thoại Download Process Template dialog box, hãy chọn vị trí thư mục trên ổ đĩa của máy của bạn, và sau đó click Save.

2. Hãy mở Process Template trong Process Editor như sau:

a. Trong Visual Studio, click vào Team menu.

b. Click Process Editor, và sau đó click Open Process Template.

c. Trong hộp thoại Open Process Template fileset dialog box, hãy chọn process template để tải về và sau đó click Open.

Và nó sẽ mở ra tập tin ProcessTemplate.xml trong Visual Studio.

d. Đặt tên Name template mà bạn muốn tùy chỉnh.

3. Trong Process Template Explorer, click Reports.

4. Trên thanh toolbar, click Add.

5. Trong hộp thoại Report dialog box, trên thẻ Report Detail tab, điền tên cho report.

6. Browse đến tập tin .rdl mà bạn muốn thêm trong trường File Name field. Hãy để các trường khác mặc định và không thực hiện bất kì thay đổi dữ liệu nào trên các thẻ Properties và thẻ Parameters tabs.

7. Trên thẻ DataSources tab, nhập tên của data sources tương ứng. Data sources mặc định đối vơi các process template có trong TFS là

/TfsOlapReportDS and /TfsReportDS.

8. Click OK.

Mã nguồn bổ sung

Bạn có thể download công cụTeam Foundation Server Power Tool từ http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx
Để có thêm thông tin về cách sử dụng công cụ Process Editor tool để tùy chỉnh các work item types, hãy xem "How To - Customize a Process Template in Visual Studio Team Foundation Server" trong tài liệu này.

Tài liệu hoàn chỉnh của phần này bạn có thể download tại đây:

Bài Tập Reporting

Bài tập : Project Management

Nguyễn Thị Như Quỳnh — Sun, 31 Jan 2010 17:45:31 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/1/2010 1:45:31 AM

Các mục

Check-in Policies

• Làm thế nào để cài đặt các chính sách check-in policy để thực thi các tiêu chuẩn về chất lượng mã.

• Làm thế nào để cài đặt các chính sách check-in policy để đảm bảo là các lập trình viên sẽ liên kết các work item với các check-in.

• Làm thế nào để cài đặt các chính sách check-in policy để thực thi các tiêu chuẩn về mã.

Project Management

• Làm thế nào để sử dụng Microsoft Project để quản lý dự án của bạn

• Làm thế nào để sử dụng Microsoft Excel để quản lý dự án của bạn

• Làm thế nào để tạo một mẫu quy trình tối thiểu

• Làm thế nào để tùy chỉnh các quy trình mẫu

• Làm thế nào để tùy chỉnh một loại work item với môt quy trình mẫu

• Làm thế nào để tùy chỉnh một loại work item với một dự án nhóm đã có

• Làm thế nào để tạo một iteration

• Làm thế nào để tạo một area

• Làm thế nào để thêm một thông báo cho sự kiện check-in

• Làm thế nào để thiết lập một report dashboard

• Làm thế nào để tạo các thư mục trong kho source control của bạn

• Làm thế nào để xóa một dự án từ Team Foundation Server

Check-in Policies

• Làm thế nào để cài đặt các chính sách check-in policy để thực thi các tiêu chuẩn về chất lượng mã.

• Làm thế nào để cài đặt các chính sách check-in policy để đảm bảo là các lập trình viên sẽ liên kết các work item với các check-in.

• Làm thế nào để cài đặt các chính sách check-in policy để thực thi các tiêu chuẩn về mã.

Làm Thế Nào Để Cài Đặt Các Chính Sách Check-In Policy Để Thực Thi Các Tiêu Chuẩn Về Chất Lượng Mã

Sử dụng một sự liên kết của chính sách phân tích mã code analysis và chính sách kiểm thử để thi hành một tiêu chuẩn chất lượng mã. Thí dụ, sử dụng chính sách kiểm thử có sẵn trong out-of-box với VSTS, để đảm bảo là các kiểm thử cụ thể được thực thi và thông qua trước khi cho phép source được check trong Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) source control. Bạn cũng có thẻ cấu hình một chính sách phân tích mã để giúp đảm bảo là mã của bạn đáp ứng được tiêu chuẩn chất lượng bằng cách đảm bảo về các quy tắc bảo mật, hiệu suất, tính tiện lợi, bảo trì và độ tin cậy được thông qua.

Bằng cách thực thi loại chính sách check-in policy này ngoài việc thi hành chính sách thực thi các tiêu chuẩn chất lượng của mã, bạn còn phải đảm bảo là mã của bạn đáp ứng được một cổng chất lượng mã cụ thể.

Để thực thi một chính sách code analysis check-in policy cho một team project

1. Trong Team Explorer, click phải lên team project của bạn, trỏ đến Team Project Settings, và sau đó click Source Control.

2. Click vào thẻ Check-in Policy tab.

3. Click Add và sau đó chọn và cấu hình chính sách tương ứng.

Mã nguồn bổ sung

Để có thêm thông tin về tạo và sử dụng một check-in policy tùy ý, hãy xem "How To - Step Through Creating Custom Check-in Policies for TFS" trong tài liệu hướng dẫn này.
Để tìm hiểu làm thế nào để tùy chỉnh một chính sách check-in policy, hãy xem"Walkthrough: Customizing Check-in Policies and Notes" tại http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx
Để xem các đoạn mã đơn giản mà không cho phép chọn các pattern trên check-in, hãy xem "Checkin Policy to Disallow Certain Patterns" tại http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx

Để xem các đoạn mã đơn giản mà sẽ thực thi các comment trên check-in,hãy xem "Sample Checkin Policy: Make Sure the Comment Isn't Empty" tại http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx

Để tìm hiểu làm thế nào để đăng kí một chính sách check-in policy mới, hãy xem "I've Made a New Check-In Policy! How Do I Add It?" tại http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx

Tài liệu hoàn chỉnh có thể download tại đây:

Bài Tập: Project Management

Bài tập : Team Build

Nguyễn Thị Như Quỳnh — Sun, 31 Jan 2010 17:41:03 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/1/2010 1:41:03 AM

Các mục

Administration

• Làm thế nào đảm bảo an toàn cho build server của bạn

• Làm sao để xóa đi một build

• Làm thế nào để xóa một loại build type

• Kết nối một work item với một build như thế nào

Check-in Policies

• Làm thế nào để sử dụng các chính sách check-in policy để cải thiện chất lượng các check-in

• Làm thế nào để sử dụng các chính sách check-in policy để kết nối các work item với các build

Continuous Integration Builds

• Làm thế nào để tự động chạy các Continuous Integration (CI) builds

• Làm thế nào để xác định nếu bạn cần một rolling build

• Làm thế nào để xác định các khoảng thời gian rolling build của bạn

Customization

• Làm thế nào để chỉnh sửa build number

• Làm thế nào để cài đặt workspace mapping để nhận và build một tập con của cây

• Làm thế nào để build một dự án với các phụ thuộc trên các team project khác

• Làm thế nào để thay đổi các cấu hình build (release/debug)

Deployment

• Làm thế nào để cài đặt một build server

• Làm thế nào để xác định nếu bạn cần nhiều build server

General

• Làm thế nào để build và triển khai một ứng dụng ASP.NET với Team Build

• Làm thế nào để build một ứng dụng Microsoft® .NET 1.1 với Team Build

• Làm thế nào để build cài đặt và triển khai các project với Team Build

• Làm thế nào để tạo một team build

• Làm thế nào để tạo nhiều loại build

• Làm thế nào để tạo một team build cho một project mà tham chiếu reference đến các assemblies từ một project khác

• Làm thế nào để mô tả những sự kiện build e-mail event

• Làm thế nào để nhận các thông báo khi một build bị thất bại

• Làm thế nào để khởi động một build

• Làm thế nào để xác nhận là build thành công

• Làm thế nào để xem một build output

• Làm thế nào để thay đổi vị trí của build server location

• Làm thế nào để thay đổi vị trí đầu ra của build output location

• Làm thế nào để xác định những tập thay đổi nào là một phần của quá trình build

• Làm thế nào để thay đổi chất lượng các build đã được báo cáo

Projects

• Làm thế nào để sử dụng chiến thuật single-solution

• Làm thế nào để sử dụng chiến thuật một partitioned-solution

• Làm thế nào để sử dụng chiến thuật một multiple-solution

Reporting

• Làm thế nào để xem chất lượng build

• Làm thế nào để xem tất cả các check-in cho một build

• Làm thế nào để xem các work item hay các bug kết thúc một build

• Làm thế nào để xem mở các work item hay các bug cho một build

• Làm thế nào để theo dõi tiến độ từ một build đến một build

• Làm thế nào để theo dõi các trường hợp kiểm thử được pass/fail results đối với một build

• Làm thế nào để xem tình trạng build status (BVT results)

Scheduled Builds

• Làm thế nào để chạy tự động các nightly builds

• Làm thế nào để xác định tần số build và loại build cho dự án của bạn

Test-Driven Development

• Làm thế nào để tạo một "hello world" acceptance test

• Làm thế nào để chạy các kiểm thử một cách tự động như một phần của quy trình build

• Làm thế nào để chạy code analysis như một phần của quy trình build

• Làm thế nào để lấy các failed tests để fail một build

Administration

• Làm thế nào đảm bảo an toàn cho build server của bạn

• Làm sao để xóa đi một build

• Làm thế nào để xóa một loại build type

• Kết nối một work item với một build như thế nào

Làm thế nào đảm bảo an toàn cho build server của bạn

Để đảm bảo an toàn cho build server của bạn

1. Triển khai các build service trên một server riêng, thay vì chia sẻ một server với tầng application hay tầng data của Microsoft Visual Studio® 2005 Team Foundation Server (TFS).

2. Cấp quyền truy cập read/write các build process trong thư mục build. Hãy đảm bảo là tài khoản đang chạy các build được phép truy cập đến thư mục này.

3. Cấp quyền truy cập read/write các build process đến các build drop network share. Hảy đảm bảo là tài khoản đan chạy các build được cấp phép cho sự chia sẻ này.

4. Hảy đảm bảo là tài khoản được sử dụng để chạy các team build là một thành viên của nhóm Team Project's Build Services group.

Để nâng cao sự bảo mật của Team Foundation Server security, bạn nên cài đặt build server trên máy tinh riêng của nó thay vì là trên tầng application hay tầng data. Hãy chỉ rõ là các bước triển khai hay build có thể đòi hỏi các đặc quyền cao; thí dụ, hãy tạo một thư mục ảo để triển khai một ứng dụng Web yêu cầu các quyền quản trị trên build server. Điều này có nghĩa là tài khoản Microsoft Windows® account đang chạy các build yêu cầu các quyền này. Nếu máy tính dùng để build là ở tầng application, thì tài khản build này sẽ đại diện cho một nguy cơ bảo mật(security risk). Tương tự, nếu máy tính dùng để build là ở tầng data, thì tài khoản build này có thể truy cập và thay đổi cơ sở dữ liệu trên tầng đó.

Lưu ý: Vì lí do bảo mật, đừng thêm bất kì tài khoản account nào đang chạy trên team build đến nhóm SERVER\ Service Accounts group. Các thành viên của nhóm này có đủ quyền quản trị trên TFS.

Tài nguyên bổ sung

Để có thêm thông tin về các nhóm và quyền TFS(TFS groups and permissions), hãy xem "Team Foundation Server Default Groups, Permissions, and Roles" tại đây http://msdn2.microsoft.com/en-us/library/ms253077(VS.80).aspx

Làm sao để xóa đi một build

Để xóa một build, bạn sử dụng công cụ TFSBuild command-line. Xác định địa chỉ của TFS server, tên của team project, và tên của build; thí dụ:

TfsBuild delete http://mytfsserver:8080 myproject build20070606.4

Tài nguyên bổ sung

Để có thêm thông tin về việc xóa một build đã hoàn thành, hãy xem "How to: Delete a Completed Build" tại http://msdn2.microsoft.com/en-us/library/aa337656(VS.80).aspx
Để có thêm thông tin về lệnh xóa, hãy xem "Delete Command (Team Foundation Build)" tại http://msdn2.microsoft.com/en-us/library/ms244360(VS.80).aspx

Làm thế nào để xóa một loại build type

Bạn không thể xóa các loại Team Build types bằng cách sử dụng Team Explorer. Thay vào đò, bạn nên xóa bỏ các build type từ source control.

Để xóa một build type đã có

1. Hãy mở Source Control Explorer.

2. Ở trong Source Control Explorer, hãy mở rộng thư mục team project folder của bạn.

3. Mở rộng TeamBuildTypes folder.

4. Click chuột phải lên Team Build folder đại diện cho Team Build type mà bạn muốn xóa và sau đó click Delete.

5. Click chuột phải lên Team Build folder một lần nữa và sau đó click Check In Pending

Changes...

6. Hãy mở Team Explorer.

7. Click chuột phải lên Team Builds folder và sau đó click Refresh.

8. Mở rộng thư mục Team Builds folder và xác nhận là Team Build đã được xóa.

Tài nguyên bổ sung

Để có thêm thông tin về Team Build, hãy xem "Overview of Team Foundation Build" tại http://msdn2.microsoft.com/en-us/library/ms181710(vs.80).aspx

Kết nối một work item với một build như thế nào

Sử dụng hộp thoại Check In đế kết nối các work item với một check-in. Hộp thoại này sẽ kết nối tự động kết nối những work item này với build tiếp theo.

Để kết nối một work item với một build

1. Hãy thay đổi mã các bạn muốn có ở trong các build và sẽ được liên kết với một work item.

2. Check in các pending changes.

3. Trong hộp thoại Check In, click Work Items.

4. Hãy chọn các work item(s) mà bạn muốn kết nối với check-in này.

Tất cả các tập thay đổi changeset mà xảy ra từ lần build thành công cuối cùng sẽ được kết nối với lần build tiếp theo. Sau lần build tiếp theo, Team Build sẽ liệt kê danh sách các changeset này trong các tập changeset kết nối đối với build và sẽ gồm có các work item được chọn đang được kết nối với changeset.

Tài nguyên bổ sung

Để có thêm thông tin về checking in pending changes, hãy xem "How to: Check In Pending Changes" tại http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx

Check-in Policies

• Làm thế nào để sử dụng các chính sách check-in policy để cải thiện chất lượng các check-in

• Làm thế nào để sử dụng các chính sách check-in policy để kết nối các work item với các build

Làm Thế Nào Để Sử Dụng Các Chính Sách Check-In Policy Để Cải Thiện Chất Lượng Các Check-In

Sử dụng một sự kết hợp giữa các chính sách phân tích code và chính sách kiểm thử(code analysis and testing policies) để cải thiện chất lượng của các check-in. Thí dụ, sử dụng các chính sách kiểm thử check-in mặc định để đảm bảo là các kiểm thử cụ thể được thực thi và thông qua trước khi cho phép phần source được check trong TFS source control. Bạn cũng có thể cấu hình một chính sách code analysis policy để giúp đảm bảo là phần code của bạn đáp ứng được các tiêu chuẩn chất lượng bằng cách đảm bảo về bảo mật, hiệu suất, bảo trì và các quy tắc về độ tin cậy được thông qua.

Để thi hành một chính sách code analysis check-in policy cho một dự án nhóm

1. Trong Team Explorer, click chuột phải lên team project của bạn, hãy chọn Team Project Settings, và sau đó click Source Control .

2. Click vào tab Check-in Policy .

3. Click Add và sau đó chọn và cấu hình các chính sách code analysis and testing policies.

Tài nguyên bổ sung

Để có thêm thông tin về tạo và sử dụng một chính sách custom check-in policy, hãy xem"How To - Step Through Creating Custom Check-in Policies for TFS" trong tài liệu này.
Để tìm hiểu làm cách nào để tùy chỉnh một check-in policy, hãy xem "Walkthrough: Customizing Check-in Policies and Notes" tại đây http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx

Để xem sample code mà không cho phép chọn các patterns trên check-in, hãy xem "Checkin Policy to Disallow Certain Patterns" tại đây http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx

Để xem sample code sẽ thực thi các comments trên check-in, hãy xem "Sample Checkin Policy: Make Sure the Comment Isn't Empty" tại đây http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx

Để tìm hiểu làm cách nào để đăng kí một chính sách check-in policy mới, hãy xem "I've Made a New Check-In Policy! How Do I Add It?" tại đây http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx

Làm Thế Nào Để Sử Dụng Các Chính Sách Check-In Policy Để Kết Nối Các Work Item Với Các Build

Sử dụng một chính sách check-in policy để thi hành từng check-in có liên kết với các work items. Các lập trình viên sử dụng hộp thoại Check In để liên kết các work item với một check-in. Hộp thoại này sẽ lien kết tự động những work item này với các build tiếp theo.

Để cài đặt chính sách work item check-in policy để buộc các lập trình viên liên kết các check-in của họ với một work item

1. Trong Team Explorer, click chuột phải lên dự án nhóm của bạn, hãy chọn Team Project Settings, và sau đó click Source Control.

2. Click vào tab Check-in Policy.

3. Click Add và sau đó chọn và cấu hình chính sách Work Item check-in policy.

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo và sử dụng một custom check-in policy, hãy xem "How To - Step Through Creating Custom Check-in Policies for TFS" trong tài liệu này.
Để tìm hiểu làm thế nào để tùy chỉnh một chính sách check-in policy, hãy xem "Walkthrough: Customizing Check-in Policies and Notes" tại đây http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx

Tài liệu hoàn chỉnh có thể download tại đây:

Bài Tập: Team Build

Hướng dẫn: Source Control

Nguyễn Thị Như Quỳnh — Sun, 31 Jan 2010 17:33:43 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 2/1/2010 1:33:43 AM

Hướng dẫn: Source Control

Các mục

Accessing Version Control

• Xem xét sử dụng các công cụ command-line tool.

• Sử dụng Microsoft® Visual Studio® 2005 Team Foundation Power Tools (TFPT) để unshelve một sự thay đổi change.

• Sử dụng Team Foundation Power Tools để phục hồi một thay đổi change.

• Sử dụng Team Foundation Power Tools để làm việc offline.

• Sử dụng Team Foundation Power Tools để lấy một changeset.

• Sử dụng Team Foundation Power Tools để remove các pending edit.

Administration

• Tắt các quyền kế thừa permission trên các nhánh maintenance branche.

• Từ chối(deny) các check-in permission cho các lập trình viên mà bạn chưa tin tưởng để thực hiện các thay đổi phần source của bạn.

Branch / Label / Merge

• Sử dụng các label để đánh dấu các build mà bạn cần phải return.

• Sử dụng các branche để phân chia các bản phát hành(release) được hỗ trợ.

• Kế hoạch cấu trúc branch của bạn dựa vào các đường dẫn merge(merge path).

• Branch tại một high level, gồm có các file cấu hình và file source.

• Không thực hiện branch quá sâu.

• Không branch nếu bạn không cần thiết.

• Tránh các merge không có cơ sở nếu có thể.

• Các full merge được ưa thích hơn là các "cherry-pick" merge.

• Merge một cách thường xuyên.

• Luôn tạo một thư mục top-level folder cho một team project mới để được xử lý như là một main branch.

• Xem xét sử dụng candidate switch hay preview switch để double-check trước khi merging.

• Khi các rename là một phần của merge, hãy chú ý đến các path mà các tool đề nghị.

• Cẩn thận khi giải quyết các xung đột trong việc merge.

• Kiểm tra các kết quả của một việc merge tại một thời điểm.

• Build và run các test sau khi merge và trước khi check-in.

Check-ins and Check-in Policies

• Chỉ check in phần code của bạn khi bạn đã sẵn sàng để share.

• Sử dụng các shelveset để back up hay là share các pending change.

• Giải quyết một work item trên một check-in.

• Sử dụng các chính sách check-in policy để thực thi các tiêu chuẩn code.

• Sử dụng các chính sách check-in policy để thực thi một cổng chất lượng code(code quality gate).

• Phát hiện khi một policy bị ghi đè.

• Lên kế hoạch để tránh các xung đột.

Checkout, Get, and Lock

• Lấy các source mới nhất trức khi thực hiện các thay đổi.

• Sử dụng các lệnh lock command tùy ý.

• Giao tiếp với các cộng sự khi khóa lock các file.

Dependencies

• Sử dụng các project reference bất cứ khi nào có thể.

• Sử dụng các file reference chỉ nơi nào cần thiết.

• Sử dụng copy local = true cho các project references và file references.

• Sử dụng các URL động khi reference các Web service.

Distributed / Remote Development

• Hãy đảm bảo là bạn nhận một ổ đĩa disk drive có kích cỡ phù hợp với proxy của bạn.

• Tạo một scheduled task để lấy(pull) các file mới nhất định kì.

• Giám sát định kì các proxy performance counter và event log.

• Cấu hình thực hiện Timeout dựa trên kích cỡ file và bandwidth.

• Disable proxy nếu nó sắp bị down trong một khoảng thời gian dài.

• Xem xét các workspace cloak để giảm thiểu việc chuyển(transfer) các file không cần thiết.

Migration

• Sử dụng VSS converter để di chuyển(migrate) đến Team Foundation Server Source Control.

• Di chuyển(migrate) từ các source-control system khác đến Team Foundation Server Source Control.

Project / Workspace Management

• Tách một nhà phát triển đơn(single developer) sử dụng các workspace chứ không phải là các branche.

• Delete và rename các file bằng cách sử dụng source control, chứ không phải là Microsoft Windows® Explorer.

• Chỉ delete và rename với solution open của bạn.

• Tạo một team project trên một application nếu bạn muốn di chuyển các asset của bạn giữa các phiên bản của ứng dụng.

• Tạo một team project trên một version nếu bạn muốn bắt đầu một cách mới hoàn toàn với từng phiên bản của ứng dụng.

• Sử dụng branchđể share các code và binaries mà có yêu cầu kiểm thử integration testing.

• Tránh các workspace mapping để hỗ trợ các phụ thuộc qua lại giữa các project.

• Tạo một workspace mapping tại team project root level.

• Sử dụng một đường dẫn local folder path duy nhất trên các shared computer.

• Cấn nhắc việc chỉ ánh xạ(map) các một phần của source tree.

• Cấu trúc source tree của bạn để hỗ trợ branching. Shelving

• Sử dụng shelving để share các pending change cho việc xem xét hoặc bàn giao.

• Sử dụng shelving để back up các pending change cho server.

• Sử dụng shelving nếu bị gián đoạn bởi các công việc ưu tiên hơn.

Accessing Version Control

• Xem xét sử dụng các công cụ command-line tool.

• Sử dụng Team Foundation Power Tools để phục hồi một thay đổi change.

• Sử dụng Team Foundation Power Tools để làm việc offline.

• Sử dụng Team Foundation Power Tools để lấy một changeset.

• Sử dụng Team Foundation Power Tools để remove các pending edit.

Xem xét sử dụng các công cụ command-line tool

Đối với các hoạt động không có sẵn trong Visual Studio, nếu bạn cần lên kế hoạch các hoạt động, hãy xem xét việc sử dụng các công cụ command-line tool như là Team Foundation Power Tools (Tfpt.exe) được cung cấp cùng với Team Foundation Server (TFS). Các công cụ Tfpt.exe tool có sẵn như một phần download riêng. Bạn có thể sử dụng các công cụ command-line tool này để lên kế hoạch các hoạt động bằng cách sử dụng Windows Task Scheduler.

Để đảm bảo là các đường dẫn path phù hợp và các môi trường khác nhau(environment variable) được cài đặt, hãy chạy Tf.exe từ Visual Studio 2005 Command Prompt window, hay chạy file Vsvars32 batch file, thường được đặt tại DriveLetter:\Program Files\Microsoft Visual Studio 8\Common7\Tools. Công cụ Tf.exe tool hỗ trợ hầu hết các lệnh source control như là Checkin, Checkout, Get, History, Shelve, Branch, Merge, Label, Status, Undelete, và Undo.

Sau đây là các hoạt động thông thường mà bạn có thể muốn thực thi từ command line bằng cách sử dụng Tf.exe:

Đồng bộ hóa các file từ server đến máy của bạn - tf get
Thêm một file vào server - tf add
Check out một file để chỉnh sửa - tf checkout
Check in các pending change - tf checkin
Lấy một changeset cụ thể từ server - tf get /version

Có một số hoạt động mà bạn chỉ có thể được thực hiện từ command line:

Delete workspace của user khác - tf workspace /delete
Undo một hành động check-in của user - tf undo
Unlock một hành động lock của user - tf lock
Định nghĩa label scope - tf label
Thực hiện một merge không có cơ sở(baseless merge) - tf merge

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Walkthrough: Working with Team Foundation Source Control from Command Line" on the Microsoft MSDN® Web site tại http://msdn2.microsoft.com/en-us/library/zthc5x3f.aspx
Để có thêm thông tin về các command mà chỉ có sẵn từ command line, hãy xem "Operations Available Only From the Command-Line (Team Foundation Source Control)" tại http://msdn2.microsoft.com/en-us/library/ms194957(VS.80).aspx

Sử dụng Team Foundation Power Tools để phục hồi một thay đổi change

The Team Foundation Power Tools (TFPT) cung cấp các chức năng version-control functionality mà không có sẵn trong Visual Studio. Thí dụ, bạn có thể sử dụng TFPT để giúp hỗ trợ các offline work hay để thực hiện các hành động rollback để undo các check-in của một changeset. Hãy xem xét sử dụng TFPT nếu bạn cần unshelve một change.

Hoạt động unshelve operation được TFS hỗ trợ, không cho phép các shelved change và các local change được merge với nhau. Bằng cách sử dụng TFPT để unshelve một change từ một changeset, nếu một item trong local workspace của bạn có một pending change là một edit, và shelved change cũng là một edit, sau đó TFPT có thể merge các change với một cách merge thứ ba.

Bạn chạy command từ command line bằng cách sử dụng Tfpt.exe.

Tài nguyên bổ sung

Để download Team Foundation Power Tools, hãy đến http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en

Để xem một forum thảo luận về Team Foundation Power Tools, hãy xem http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1

Sử Dụng Team Foundation Power Tools Để Roll Back Các Change

Xem xét sử dụng TFPT nếu bạn cần roll back một change. Khả năng undo một check-in của một changeset không được hỗ trợ trực tiếp trong TFS. Bằng cách sử dụng TFPT rollback command, bạn có thể cố gắng undo bất kì change nào được thực hiện trong một changeset cụ thể. Không phải tất cả các change đều được roll back, nhưng các rollback được thực hiện trong hầu hết các scenario.

Bạn chạy dòng lệnh này từ command line bằng cách sử dụng Tfpt.exe.

Tài nguyên bổ sung

Để download Team Foundation Power Tools, hãy đến

http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en

Để xem một forum đang thảo luận về Team Foundation Power Tools, hãy xem

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1

Sử dụng Team Foundation Power Tools để làm việc offline

Offline working không được hỗ trợ trong TFS. Nếu bạn muốn work offline, bạn phải tuân thủ nghiêm ngặt các workflow sau đây:

1. Remove bằng tay các read-only flag.

2. Edit các file.

3. Add hay delete các file

4. Run the TFPT online command.

Mỗi bước được mô tả chi tiết dưới đây.

Quan trọng: Bạn phải rename bất kì file nào trong khi bạn offline.

1. Remove bằng tay các read-only flag.

Mặc định, tất cả các file trong workspace mà không được check out sẽ được đánh dấu là read-only. Khi bạn làm việc mà không có một server connection, bạn phải remove bằng tay các read-only flag khỏi các file trước khi chỉnh sửa hay xóa chúng. Để làm điều này, hãy click chuột phải vào file trong Windows Explorer, click Properties, xóa đi Read-only check box, và sau đó click OK. Ngoài ra, bạn có thể sử dụng DOS command attrib -r.

2. Edit các file.

Bây giờ bạn có thể chỉnh sửa edit bất kì file nào mà bạn đã remove đi read-only flag.

3. Add hay delete các file

Bạn có thể thêm hay xóa các file mà bạn đã remove đi read-only flag. Đừng rename các file, bởi vì công cụ TFPT online tool không phân biệt được một hành động rename từ một hành động xóa được ghép với một hành động thêm.

Lưu ý: Bạn phải xác định một lựa chọn Tfpt online command để có được nó để tìm kiếm các hành động xóa, vì đây là thời gian dành cho các hoạt động.

4. Run the TFPT online command.

Khi bạn quay lại online, hãy chạy lệnh TFPT online command bằng cách đánh các lệnh TFPT online ở trong command line. Lệnh này sẽ scan workspace của bạn đối với các file có thể ghi được và xác định những thay đổi nào nên được treo(chưa quyết định) trên server. Nếu bạn đã xóa bất kì file nào, hãy sử dụng chuyển đổi /delete switch. Lệnh này nói cho tool là đế scan đối với các file đã delete trong workspace của bạn. Công cụ tool sẽ hiển thị cửa sổ online window mà bạn có thể chọn những thay đổi để pend trong workspace.

Tài nguyên bổ sung

Để download Team Foundation Power Tools, hãy đến

http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en

Để xem một forum đang thảo luận về Team Foundation Power Tools, hãy xem tại http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1

Sử Dụng Team Foundation Power Tools Để Lấy Một Changeset

Xem xét sử dụng TFPT nếu bạn cần lấy một changeset. The TFPT GetCS command cho phép bạn nhận tất cả các item được liệt kê trong một changeset tại thời điểm của changeset version. Điều này có ích nếu một đồng nghiệp đã kiểm tra một change mà bạn cần có trong workspace của bạn, nhưng bạn không thể thay đổi toàn bộ workspace cho version mới nhất.

Bạn chạy lệnh này từ command line bằng cách sử dụng Tfpt.exe.

Tài nguyên bổ sung

Để download Team Foundation Power Tools, hãy đến

http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en

Để xem một forum đang thảo luận về Team Foundation Power Tools, hãy xem tại

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1

Sử Dụng Team Foundation Power Tools Để Remove Các Pending Edit

Xem xét sử dụng TFPT nếu bạn cần remove các pending edit từ các file. The TFPT Undo Unchanged command remove các pending edit từ các file mà không chưa thực sự được edit. Điều này có ích trong một scenario nơi mà bạn check out một số lượng lớn các file cho việc edit, nhưng chỉ thực hiện các thay đổi thực sự đến một số lượng nhỏ các file. Bạn có thể undo các edit của bạn trên các file chưa được thay đổi bằng cách chạy TFPT UU tool, mà so sánh các hash của các file trong local workspace để hash trên server để xác định các file có thực sự được edit hay không.

Bạn chạy lệnh này từ command line bằng cách sử dụng Tfpt.exe.

Tài nguyên bổ sung

Để download Team Foundation Power Tools, hãy đến

http://www.microsoft.com/downloads/details.aspx?familyid=7324C3DB-658D-441B-8522-689C557D0A79&displaylang=en

Để xem một forum đang thảo luận về Team Foundation Power Tools, hãy xem tạihttp://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&SiteID=1

Administration

• Không cho phép các quyền kế thừa permission trên các nhánh maintenance branche.

• Từ chối(deny) các check-in permission cho các lập trình viên mà bạn chưa tin tưởng để thực hiện các thay đổi phần source của bạn.

Không Cho Phép Các Quyền Kế Thừa Permission Trên Các Nhánh Maintenance Branche.

Mỗi một branch được bảo trì- thí dụ, sau khi bạn chuyển một version của phần mềm của bạn- bạn có thể tắt các inherite permission để lock down cái cây tree. Sau khi thực hiện điều này, bạn có thể cấp cho cá nhân các user quyền PendChange và Checkin permission khi cần thiết để sữa chữa kịp lúc.

Tài nguyên bổ sung

Để có thêm thông tin về removing permissions, hãy xem "How to: Remove Access to Source Control Files" tại http://msdn2.microsoft.com/en-us/library/ms400718(VS.80).aspx

Từ Chối(Deny) Các Check-In Permission Cho Các Lập Trình Viên Mà Bạn Chưa Tin Tưởng Để Thực Hiện Các Thay Đổi Phần Source Của Bạn

Bạn có thể từ chối deny các check-in permission trên source tree đối với các lập trình viên mà bạn chưa tín nhiệm, như là nhân viên mới thuê hay các nhân viên thực tập. Hãy chắc là bạn đã thiết lập các permission mong muốn của bạn (kể cả các permission cho account của bạn) trước khi tắt chế độ inheritance. Thay vì check in một cách trực tiếp, họ có thể thực hiện các pending change và sau đó shelve những thay đổi này. Một lập trình viên có thêm nhiều kinh nghiệm sau khi unshelve các thay đổi change, review lại, và kiểm tra check in chúng.

Tài nguyên bổ sung

Để có thêm thông tin về remove các permission, hãy xem "How to: Remove Access to Source Control Files" tại http://msdn2.microsoft.com/en-us/library/ms400718(VS.80).aspx

Tài liệu hoàn chỉnh của phần này bạn có thể download tại đây:

Hướng dẫn: Source Control

Hướng dẫn: Reporting

Nguyễn Thị Như Quỳnh — Mon, 21 Dec 2009 06:25:31 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/21/2009 2:25:31 PM

Mục

Administration

• Đảm bảo là các user ở trong các nhóm security group một cách chính xác.

• Tạo một report dashboard để xem tình trạng project status và các số liệu chất lượng tại một vị trí.

Creating / Customizing

• Hãy chắc là server name phải đúng khi triển khai các report.

• Tạo các scheduled report snapshots mà bạn có thể xem theo thời gian.

• Chỉnh sửa các report đã có để truy cập được đến các data bổ sung.

Viewing

• Hãy chắc là warehouse Web service đã chạy nếu bạn muốn có data mới nhất.

Administration

• Đảm bảo là các user ở trong các nhóm security group một cách chính xác.

• Tạo một report dashboard để xem tình trạng project status và các số liệu chất lượng tại một vị trí.

Đảm bảo là các user ở trong các nhóm security group một cách chính xác

Nếu bạn muốn một user có thể triển khai các reports, hãy chắc là user đó được phân công report server's Content Manager Role. The Content Manager role là một Report Services role được xác định trước cho các user mà triển khai và quản lý các report và các kết nối đến data source ở trên Web server. Đối với một Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) user có thể triển khai các report đến report server, thì user phải là một thành viên có vai trò này.

Để thêm một user vào Content Manager role

1. Mở trang report site cho project. Ở trong Team Explorer, right-click vào Reports entry cho team project của bạn và sau đó chọn Show Report Site.

2. Trên đầu của cửa sổ window, click vào thẻ tab Properties.

3. Phía bên trái của cửa sổ window, click Security.

4. Click New Role Assignment.

5. Trong Group or user name: field, điền tên của user hay group mà bạn muốn để thêm Content Manager role

6. Chọn Content Manager check box.

7. Click OK.

Tài nguyên bổ sung

Để có thêm thông tin về Content Manager role, hãy xem "Content Manager Role" tại http://technet.microsoft.com/en-us/library/ms159693(SQL.90).aspx
Để có thêm thông tin về các security role trong tầng data tier, hãy xem "Securing Access Through Analysis Services" tại http://msdn2.microsoft.com/en-us/library/ms174839.aspx
Để có thêm thông tin về các security roles ở tầng application tier, hãy xem "Securing Reporting Services" tại http://msdn2.microsoft.com/en-us/library/ms157198.aspx

Tạo Một Report Dashboard Để Xem Tình Trạng Project Status Và Các Số Liệu Chất Lượng Tại Một Vị Trí

Một reporting dashboard cho phép bạn và nhóm của bạn truy cập một cách nhanh chóng các thông tin project quan trọng trên một single page. Trang Microsoft Office SharePoint® portal page mặc định cho Microsoft Solution Framework (MSF) cho các dự án Agile Software Development (MSF Agile) projects chứa một single report cũng như liên kết đến các cái khác. Để tạo một single repository cho thông tin của dự án project information, bạn có thể chỉnh sửa trang portal page đối với MS Agile hay MSF cho các CMMI® (MS CMMI) project để gồm có rất nhiều report ở trên trang mà bạn muốn.

Thí dụ, một reporting dashboard có ích có thể chứa các report sau:

• Remaining Work

• Quality Indicators

• Bug Rates

• Project Velocity

Bạn có thể thêm các report mới vào trang SharePoint portal của bạn bằng cách thêm một Report Viewer Web Part cho từng report mà bạn muốn hiển thị lên trang đó.

Để chỉnh sửa team project portal và tạo một reporting dashboard

1. Install the Report Viewer Web Part trên report server của bạn sử dụng công cụ stsadm.exe tool và RSWebParts.cab, cả hai đều được tích hợp với SharePoint và Report Services installation package.

STSADM.EXE có thể được tìm thấy theo đường dẫn sau: C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\BIN
RSWebParts.Cab có thể được tìm thấy theo đường dẫn sau: C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint Example: STSADM.EXE -o addwppack -filename "C:\ Program Files\Microsoft SQL Server\90\Tools\Reporting Services\SharePoint\RSWebParts.cab" -globalinstall

2. Trong Team Explorer, right-click vào project của bạn.

3. Click Show Project Portal.

4. Click Modify Shared Page.

5. Trỏ đến Browse và sau đó click Add Web Parts.

6. Click Virtual Server Gallery.

7. Ở trong Web Part List, hãy chọn Report Viewer.

8. Click Add.

9. Điền tên Report Manager name, như là http://<report server>/reports.

10. Điền đường dẫn path cho report mà bạn muốn hiển thị, như là <my project>/Quality Indicators.

Tài nguyên bổ sung

Để có thêm thông tin về thêm một Report Viewer Web Part, hãy xem "Viewing Reports with SharePoint 2.0 Web Parts" tại

http://msdn2.microsoft.com/en-us/library/ms159772(SQL.90).aspx

Để có thêm thông tin về team project portal, hãy xem "Using the Team Project Portal" tại http://msdn2.microsoft.com/en-us/library/ms242883(VS.80).aspx

Creating / Customizing

• Hãy chắc là server name phải đúng khi triển khai các report.

• Tạo các scheduled report snapshots mà bạn có thể xem theo thời gian.

• Chỉnh sửa các report đã có để truy cập được đến các data bổ sung.

Hãy Chắc Là Server Name Phải Đúng Khi Triển Khai Các Report

Nếu cả report server's Uniform Resource Locator (URL) hay Target Folder Name được xác định không chính xác, thì report của bạn có thể không được triển khai đến report server. Khi bạn triển khai một report từ Visual Studio 2005, hãy xác định URL của server mà report nên được triển khai và tên của team project mà report là một phần của nó. URL của report server mà report được triển khai là

http://TeamServerName/ReportServer, là nơi mà ReportServer là điểm cuối của Report Server Web service.

Xác định tên của team project ở trong TargetReportFolder field của hộp thoại deployment properties dialog box. Giá trị này là case-sensitive; nếu bạn nhận được các case sai, report sẽ được triển khai nhưng không xuất hiện trong danh sách của các report dành cho team project của bạn ở trong Team Explorer.

Tài nguyên bổ sung

Để có thêm thông tin về cài đặt các thuộc tính deployment properties, hãy xem "How to: Set Deployment Properties (Report Designer)" tại http://technet.microsoft.com/en-us/library/ms155802(SQL.90).aspx

Tạo Các Scheduled Report Snapshots Mà Bạn Có Thể Xem Theo Thời Gian

Sử dụng report history để build các snapshot của project data tại những khoảng thời gian đều đặn. Bạn có thể xem những snapshots này qua một giai đoạn thời gian cũ thể để hiểu rõ hơn về các xu hướng, hay là để nhớ các điểm data quan trọng trong suốt thời gian mà project của bạn thực hiện.

Để tạo một scheduled report snapshot

1. Mở một report từ report portal.

2. Click the Properties tab.

3. Click the History link.

4. Cài đặt một lịch trình để khi nào bạn muốn snapshot chạy.

Sau khi cài đặt một lịch trình trước, bạn có thể tìm thấy các snapshot ở trên tab History cho report đó. Bạn cũng có thể tạo các snapshot bằng tay trên History tab.

Chỉnh Sửa Các Report Đã Có Để Truy Cập Được Đến Các Data Bổ Sung

Chỉnh sửa các report bằng cách sử dụng Microsoft SQL Server^TM 2005 Reporting Services Designer inside Visual Studio (Business Intelligence Development Studio), mà được chuyển với các SQL Server 2005 client tool.

Tùy chỉnh một report cho phép bạn thêm các chức năng của một report đã có mà không cần phải build một report mới. Nếu một report mà bạn cần tương tự như một report đã có, hãy tùy chỉnh cái đã có để tiết kiệm thời gian. Để tùy chỉnh một report đã có, bạn phải export nó từ report server, thêm nó vào một report project đã có trong Visual Studio, và triển khai nó lại đến reporting portal sau khi đã được thay đổi.

Lưu ý: Mặc dù bạn có thể sử dụng Report Builder có sẵn từ trang team reporting site, nhưng công cụ này không được hỗ trợ tốt cho các kịch bản Visual Studio reporting scenarios và vì thế mà không khuyến khích sử dụng.

Tài nguyên bổ sung

Để có thêm chi tiết về How To article, hãy xem "How To - Customize a Report in Visual Studio Team Foundation Server" trong tài liệu này.
Để có thêm thông tin về reporting, hãy xem "Chương 15 - Reporting Explained" trong tài liệu này.
Để có thêm các tutorial giải thích về làm thế nào để làm việc với các reporting projects, hãy xem "Reporting Services Tutorials" tại

http://msdn2.microsoft.com/en-us/library/ms170246.aspx

Để đọc một Microsoft MSDN® article about editing reports, hãy xem "How to: Edit Reports in Report Designer" tại

http://msdn2.microsoft.com/en-us/library/ms244655(VS.80).aspx

Viewing

• Hãy chắc là warehouse Web service đã chạy nếu bạn muốn có data mới nhất.

Hãy Chắc Là Warehouse Web Service Đã Chạy Nếu Bạn Muốn Có Data Mới Nhất

Chạy các warehouse Web service bằng tay nếu bạn muốn đảm bảo là các report của bạn có các thông tin dữ liệu mới nhất. Mặc định, warehouse Web service chạy một lần mỗi giờ để tạo các data cho report của bạn.Nếu bạn chạy một report và muốn đảm bảo là các report của bạn chứa các dữ liệu mới nhất, bạn có thể chạy các service bằng tay.

Để chạy các warehouse service bằng tay:

1. Mở Internet Information Services (IIS) Manager.

2. Chọn phần Team Foundation Server Web site.

3. Với Web site, hãy mở Warehouse\v1.0 directory. Nó sẽ hiển thị một trang với một danh sách các operation có sẵn trong warehouse.

4. Right-click warehousecontroller.asmx và sau đó click Browse.

5. Click Run và sau đó click Invoke. Thực hiện điều này sẽ mở ra một browser window thứ hai hiển thị tình trạng của run request. Nó nên hiển thị giá trị true.

6. Trở lại browser window đầu tiên và navigate back các operations page.

7. Hãy chọn GetwareHouseStatus và sau đó click Invoke. Điều này sẽ hiển thị các tình trạng hiện tại của các warehouse Web service. Một giá trị của idle chỉ ra là warehouse đã chạy. Các giá trị khác hiển thị tình trạng của service.

Tài nguyên bổ sung

Để có thêm thông tin về troubleshooting the warehouse, hãy xem "Troubleshooting the Data Warehouse" tại http://msdn2.microsoft.com/en-us/library/ms244674(vs.80).aspx

Team Foundation Reporting Resources

Để có thêm thông tin về reporting, hãy xem"Team Foundation Server Reporting" tại http://msdn2.microsoft.com/en-us/library/ms194922(VS.80).aspx

Hướng dẫn: Project Management (phần 2)

Nguyễn Thị Như Quỳnh — Mon, 21 Dec 2009 06:23:20 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/21/2009 2:23:20 PM

Team Projects

• Tạo một team project trên một ứng dụng nếu bạn muốn di chuyển các work item và các phần khác giữa các version(phiên bản) của ứng dụng.

• Tạo một team project trên một version nếu bạn muốn khởi động với các work item mới và các asset khác với từng version(phiên bản) của ứng dụng.

• Chỉ cấp các permission được yêu cầu trên các project assets.

• Cấu trúc source tree của bạn để hộ trợ branching.

Tạo Một Team Project Trên Một ứng Dụng Nếu Bạn Muốn Di Chuyển Các Work Item Và Các Phần Khác Giữa Các Version(Phiên Bản) Của ứng Dụng

Nếu bạn muốn thực hiện chuyển tiếp không chỉ là source code mà còn là các work item và các TFS asset khác giữa các bản phát hành release, hãy xem xét sử dụng một team project trên một ứng dụng. Khi bạn sử dụng một single team project cho nhiều version của ứng dụng, tất cả các TFS asset đều được chuyển tiếp một cách tự động cho các bản phát hành kế tiếp. Khi bạn đã sẵn sàng để phát hành một version mới của ứng dụng của bạn, bạn có thể tạo một branch với project để đại diện cho các bản phát hành release và tách riêng phần code đó.

Hãy nhớ các điểm chính sau khi sử dụng một project trên một application:

Các bản phát hành song song buộc phải chia sẻ các sơ đồ work items schema, check in policies, và các hướng dẫn về quy trình.
Các báo cáo report thì khó hơn; bởi vì các report mặc định cho toàn bộ dự án project, bạn phải thêm filter bằng các release.
Nếu bạn có hàng trăm ứng dụng, từng project riêng, bạn sẽ khởi động dựa vào giới hạn về hiệu suất và tỉ lệ của TFS.
Bạn sẽ tích lũy 'baggage' qua nhiều bản phát hành release. Cách dễ nhất để ghi nhận lại vấn đề này là tạo mới một project và branch phần code mà bạn muốn thực hiện chuyển tiếp vào project đó.

Tài nguyên bổ sung

Để có thêm thông tin về sử dụng các team project, hãy xem "When to use Team Projects" tại http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx

Tạo một team project trên một version nếu bạn muốn khởi động với các work item mới và các asset khác với từng version(phiên bản) của ứng dụng

Nếu bạn muốn mỗi bản phát hành bắt đầu một cách mới hoàn toàn mà không thực hiện chuyển tiếp các work item và các TFS asset khác, thì hãy xem xét sử dụng một project trên một release. Khi bạn sử dụng một project mới cho từng release, bạn có thể chỉnh sửa work item schema, workflow, check-in policies, và các asset khác mà không ảnh hưởng đến các bản phát hành release cũ. Điều này có thể đặc biệt hữu dụng nếu bản phát hành cũ sẽ không được bảo trì bởi một nhóm riêng nào đó như là một nhóm kĩ sư được duy trì liên tục mà có thể có một quy trình và tiến trình công việc workflow khác so với nhóm phát triển chính của bạn.

Hãy nhớ các điểm chính sau khi sử dụng một project trên một bản phát hành release:

Mặc dù dễ dàng để di chuyển source code từ một project sang project khác, nhưng lại khó di chuyển các work item và các TFS asset khác từ một project sang project khác. Bởi vì các work item chỉ có thể được copy tại một thời điểm đến project khác, nếu bạn muốn copy một tập các work item, bạn sẽ cần viết tiện ích của riêng bạn.
Nếu bạn có hàng trăm các ứng dụng và bản phát hành, mỗi cái ở trong project của riêng nó, bạn sẽ khởi động dựa trên các giới hạn về hiệu suất và tỉ lệ của TFS(TFS performance and scale limit).
Hãy chọn một cấu trúc mà bạn có thể tương tác làm việc trong một thời gian dài bởi vì cấu trúc lại các team project rất khó khăn.
Source có thể dễ dàng được chia sẻ giữa các team project như sau:

o Branch source từ một project này đến project khác.
o Map source từ project khác vào workspace của bạn.

Team Foundation Server có thể đạt đến tỉ lệ ~500 project bằng cách sử dụng quy trình mẫu MSF Agile process template hay là 250 project bằng cách sử dụng quy trình mẫu MSF CMMI process template. Nếu bạn tạo quy trình mẫu của riêng mình hay là tùy chỉnh một quy trình mẫu đã có, hãy nhớ là các work item schema có ảnh hưởng lớn nhất đến khả năng mở rộng server. Một schema phức tạp sẽ trả về kết quả trong một server có khả năng hỗ trợ một số ít các project.
Bạn sẽ phải thực hiện trên tất cả các area từ project gốc; và cũng có lẽ thay đổi các permission ở trong source control.

Tài nguyên bổ sung

Để có thêm thông tin về việc sử dụng các team project, hãy xem "When to use Team Projects" tại http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx

Chỉ cấp các permission được yêu cầu trên các project assets

Khi tạo các team project, hãy xem lại các security group mặc định được tạo bởi các quy trình, và nếu cần, hãy tạo các security group với các permission phù hợp. Sau đó bạn phân chia các thành viên của dự án vào các group tương ứng để đảm bảo là mỗi thành viên sẽ chỉ nhận các permission mà anh ta hay cô ta yêu cầu trên các project asset.

Tài nguyên bổ sung

Để có thêm thông tin về cấp phát các permission, hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server" trong tài liệu này.

Cấu trúc source tree của bạn để hộ trợ branching

Khi tạo cấu trúc cây source tree của bạn, hãy đảm bảo là nó hỗ trợ branching. Hãy giữ các folder dành riêng cho source và cho các project asset khác, để nếu các phát triển isolation development được yêu cầu trong tương lai, bạn có thể branch một cách đơn giản source folder. Và cũng hảy đảm bão là bạn duy trì các folder dành riêng cho từng thành phần với source folder, để partial branching có thể được thực thi nếu có yêu cầu.

Hãy chia các thực thể khác ra như là shared code, unit tests, library dependencies, và vv... bằng cách sử dụng các folder mà chúng có thể được loại trừ hoặc gồm có trong suốt quá trình branch theo yêu cầu.

Sau đây là một thí dụ của một cấu trúc source tree mà có hỗ trợ branching:

Tài nguyên bổ sung

Để có thêm thông tin về source tree structure, hãy xem "Chương 5 - Defining Your Branching and Merging Strategy" trong tài liệu này.

Work Items

• Nắm bắt các kịch bản/tình huống của bạn ngay lúc bắt đầu dự án project của bạn.

• Xác định các yêu cầu Quality of Service một cách thích hợp.

• Phân chia các kịch bản scenarios thành các task quản lý, mô- đun task phát triển.

• Thiết lập từng tiêu chuẩn cơ bản cho từng task.

• Liên kết các requirement và các task cho các kịch bản.

• Sử dụng Microsoft Excel để chỉnh sửa một số lượng lớn các work item.

Nắm bắt các kịch bản/tình huống của bạn ngay lúc bắt đầu dự án project của bạn

Tạo và nắm bắt một tập các kịch bản dự án(project scenarios) vào lúc bắt đầu project cảu bạn. Điều này giúp bạn đạt được một bức tranh tổng thể về project của bạn và sau này có thể được sử dụng để theo dõi các tiến bộ của dự án của bạn. Trong suốt quá trình phát triển, bạn có thể chỉnh sửa các kịch bản đã có hay thêm mới các kịch bản để miêu tả trình bày cho những gì mà bạn học được theo thời gian.

Để nắm bắt các kịch bản vào lúc bắt đầu dự án

1. Sử dụng project back log (PBL) document, là các document được yêu cầu dựa trên đầu vào từ các stakeholder khác nhau (bao gồm các customers, business analysts, end users, và các product managers), và phạm vi của các kịch bản cho project của bạn.

2. Ở trong Team Explorer, hãy mở rộng nút project node, right-click vào Work Items folder, trỏ đến phần Add Work Item, và sau đó click Scenario.

3. Ở trong trang mới New Scenario page, hãy enter các chi tiết cho scenario. Hãy chắc là để thiết lập Iteration đến Iteration 999.

4. Save kịch bản scenario mới của bạn.

5. Lặp lại các bước trên cho tất cả các kịch bản scenarios mà bạn đã xác định cho project.

Tài nguyên bổ sung

Để có thêm thông tin về capturing scenarios, hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server" trong tài liệu này.

Xác định các yêu cầu Quality of Service một cách thích hợp

Hãy xác định các yêu cầu Quality of Service (QoS) requirement cho từng kịch bản scenarios để được làm việc trong suốt chu kì lặp iteration cycle. Điều này giúp định nghĩa các tiêu chuẩn được chấp nhận cho kịch bản scenario. Những đầu vào input cho các QoS requirement là từ các mục đích của poject và các yêu cầu và các tài liệu cụ thể, nếu có sẵn.

Để xác định các yêu cầu QoS requirement của bạn:

1. Right-click vào mục project's Work Items folder, trỏ đến phần Add Work Item, và sau đó click vào Quality of Service Requirements.

2. Trên trang New Quality of Service Requirements page, thêm vào các chi tiết sau:

a. Gán Type cho một giá trị thích hợp như là performance, scalability, stress, hay security.

b. Gán Iteration thành current iteration cycle.

c. Từ tab Links, liên kết QoS đến một kịch bản scenario cụ thể để truy tìm nguồn gốc dễ dàng hơn.

3. Save yêu cầu QoS requirement mới.

4. Tạo một QoS requirement cho từng quy tắc hay từng loại yêu cầu chất lượng, và hãy nhớ là mỗi kịch bản scenario có thể có nhiểu yêu cầu QoS requirements.

5. Hãy chắc là bạn tạo các yêu cầu QoS requirements cho tất cả các kịch bản scenarios đang được làm việc trong suốt các vòng lặp cụ thể(iteration cycle)

Quan trọng: Sau này bạn có thể phân chia các yêu cầu QoS requirements thành các test task.

Tài nguyên bổ sung

Để có thêm thông tin về xác định các yêu cầu QoS requirements, hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server" trong tài liệu này.
Để có thêm thông tin về các work item , hãy xem "Managing Team Foundation Work

Items" tại http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx

Phân chia các kịch bản scenarios thành các task quản lý, mô- đun task phát triển.

Trong quá trình lập kế hoạch iteration, hãy chia các kịch bản của bạn thành các câu chuyện của người dùng và sau đó phân chia các câu chuyện của người dùng thành các tác vụ phát triển development task. Hãy chắc là các tác vụ phát triển development task mà bạn tạo ra có thể quản lý được và phân chia thành các modul. Các tác vụ task không nên là cuối cùng nhiều hơn một hoặc hai ngày. Nếu chúng nhiều hơn, bạn cần phải phân chia các tác vụ task thành các tác vụ task nhỏ hơn hay các sub-task. Việc làm này tạo nên các kế hoạch linh hoạt và cải thiện quản lý dự án.

Để chia các kịch bản scenarios thành các tác vụ phát triển có thể quản lý được và theo từng modul:

1. Chia các kịch bản scenario đã chọn thành các developer stories.

2. Chia nhỏ các developer stories thành các tác vụ developer task.

3. Nắm bắt các tác vụ developer task trong TFS như là các task work item như sau:

a. Trong Team Explorer, bên dưới project node của bạn, right-click vào Work Items folder, trỏ đến Add Work Item, và sau đó click Task.

b. Trên trang New Task page, thêm các chi tiết sau:

i. Gán Discipline thành Development.

ii. Gán Iteration thành iteration cycle hiện có.

iii. Trên tab Links, liên kết task với các scenario cụ thể để truy tìm nguồn gốc dễ hơn. Trên tab này, cùng với sự mô tả, bạn có thể nắm bắt các tiêu chuẩn chấp nhận được cho tác vụ task, mà có thể xác định nếu tác vụ được hoàn thành thành công.

iv. Gán Assigned to field cho lập trình viên mà sẽ làm tác vụ đó.

c. Save task mới.

d. Lặp lại các bước trên cho tất cả các task đã xác định.

4. Lặp lại các bước trên cho tất cả các scenario đã xác định đối với iteration.

Tài nguyên bổ sung

Để có thêm thông tin về các kịch bản scenarios, hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server" trong tài liệu này.
Để có thêm thông tin về các work items, hãy xem "Managing Team Foundation Work Items" tại http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx

Thiết Lập Từng Tiêu Chuẩn Cơ Bản Cho Từng Task

Các tác vụ phát triển development task, khi xác định, nên gồm có các tiêu chuẩn chấp nhận được để cho phép một lập trình viên quyết định khi tác vụ task được hoàn thành. Dựa trên các quy trình mẫu mà bạn đang sử dụng, thì có thể thực hiện được theo 2 cách:

MSF Agile - Nếu bạn đang sử dụng MSF Agile mà không có một yêu cầu loại work item chính thức, tốt nhất là hãy bao gồm các tiêu chuẩn chấp nhận được(acceptance criteria) như là text trong chính các work item. Hãy bắt đầu với một danh sách với các gạch đầu dòng và thêm nhiều chi tiết hơn nếu cần thiết.
MSF CMMI - Nếu bạn đang sử dụng MSF CMMI, bạn có thể sử dụng các yêu cầu formal để xác định các acceptance criteria cho một task. Bước đầu tiên là xác định các yêu cầu của bạn. Sau đó bạn có thể tạo các development task mà sẽ được sử dụng để thực thi những yêu cầu này và liên kết các task với các yêu cầu để các lập trình viên có thể kiểm tra dựa vào đó và để có sự truy tìm nguồn gốc từ các yêu cầu đến các task.

Các tiêu chuẩn chấp nhận được acceptance criteria thường hầu hết được xác định như là một yêu cầu kinh nghiệm người dùng trong một form của một mini-scenario hay một yêu cầu về QoS(QoS requirement). Sau khi acceptance criteria đã được đáp ứng, các lạp trình viên có thể đánh dấu các task đã hoàn thành và chuyển sang task tiếp theo.

Tài nguyên bổ sung

Để có thêm thông tin về các work items, hãy xem "Managing Team Foundation Work Items" tại http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx

Liên Kết Các Requirement Và Các Task Cho Các Kịch Bản

Khi tạo mới các work item như là các tasks, bugs, issues, hay các QoS requirements, hãy chắc là bạn liên kết những work item này đến các scenario mà điều khiển các sự khởi tạo của chúng. Điều này giúp đả bảo là mỗi work item được điều khiển bởi một kịch bản người dùng thật sự(real user scenario) và có thể được sử dụng để theo dõi tiến độ hoàn thành kịch bản trong suốt quá trình development iteration của bạn.

Để liên kết các tasks, bugs, issues, hay các QoS work item mới đến kịch bản scenarios

1. Trong trang New work item page, click vào tab Links , trên tab Links hãy click vào buton Add.

2. Trong hộp thoại Add Link dialog box, bên dưới Link Type, hãy chọn Scenario.

3. Click vào Browse để tìm kiếm các kịch bản scenarios ở trong team project của bạn.

4. Trong danh sách list, hãy chọn scenario mà bạn muốn liên kết đến và sau đó click OK.

5. Trong Comment box, hãy đánh một comment để giải thích các work item liên quan đến như thế nào. Hộp Description box được điền một cách tự động.

6. Click OK.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server"trong tài liệu này.
Để có thêm thông tin về các work items, hãy xem "Managing Team Foundation Work Items" tại http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx

Sử Dụng Microsoft Excel Để Chỉnh Sửa Một Số Lượng Lớn Các Work Item

Team Foundation Server không hỗ trợ việc chỉnh sửa work item số lượng lớn. Thay vào đó, bạn phải chỉnh sửa từng work item một cách riêng lẻ. Nếu bạn cần chỉnh sửa một số lượng lớn các work item trong một thời gian ngắn-thí dụ, trong một cuộc họp phân loại-hãy cân nhắc việc sử dụng Microsoft Office Excel® để giảm bớt các task. Các work item có thể được export từ TFS đến Excel, chỉnh sửa , và sau đó import trở lại vào TFS để giữ lại bất kì sự thay đổi mà bạn đã thực hiện.

Để tạo một danh sách các work item list trong Excel và chỉnh sửa chúng:

1. Trong Microsoft Office Excel, trên Team menu, click New List.

2. Bên dưới Connect to a Team Foundation Server, hãy chọn server để kếtnối đến, hay là click vào Servers để enter vào thông tin của server.

3. Bên dưới Team Projects, hãy chọn team project trên Team Foundation Server mà bạn muốn làm. Tài liệu này sẽ bị ràng buộc với team project này.

4. Click OK.

5. Chọn loại danh sách mà bạn muốn. Để tạo một danh sách truy vấn query list, hãy chọn Query List option và sau đó chọn một team query từ danh sách drop-down Select a Query drop-down list.

6. Hãy chọn các column mà bạn muốn nó xuất hiện trong danh sách mới các work item.

7. Import các work item mà bạn muốn. Để có thêm thông tin, hãy xem How to: Import Work Items in Microsoft Excel or Microsoft Project tại

http://msdn2.microsoft.com/en-us/library/ms181676(VS.80).aspx

8. Bây giờ bạn có thể chỉnh sửa các work item và sau đó publish các work item đã cập nhật vào work item database bằng cách click vào Publish Changes ở trên Team menu.

Tài nguyên bổ sung

Để có thêm thông tin về việc sử dụng Microsoft Office Excel cho các project-management tasks, hãy xem "Working with Work Item Lists in Microsoft Excel" tại

http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx

Team Foundation Project Management Resources

Để có thêm thông tin về MSF process templates, hãy xem "Process Templates" tại

http://msdn2.microsoft.com/en-us/teamsystem/aa718801.aspx

Hướng dẫn: Project Management

Nguyễn Thị Như Quỳnh — Mon, 21 Dec 2009 06:17:04 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/21/2009 2:17:04 PM

Mục

Areas and Iterations

• Sử dụng các area để truy nguyên nguồn gốc tốt hơn.

• Sử dụng các iteration để đại diện cho các sự kiện quan trọng ở trong project của bạn.

• Tạo một Separate Iteration cho các nhiệm vụ task và các kịch bản scenario không xác định.

• Xác định thời gian chu kì lặp(iteration cycle duration) thích hợp.

Check-in Policies

• Sử dụng các check-in policies để thực thi các quy định về chất lượng code.

• Sử dụng các check-in policies để đảm bảo là các lập trình viên kết nối các work item với các check-in.

• Tại các check-in policies để thi hành các tiêu chuẩn về code.

• Cài đặt các lưu ý để thông báo cho bạn khi các lập trình viên bỏ qua các check-in policies.

Process Templates

• Sử dụng quy trình mẫu MSF Agile khi đang làm việc trên các project mà chỉ yêu cầu một quy trình ít quan trọng hay không chính thức.

• Sử dụng quy trình mẫu MSF CMMI khi làm việc trên các project yêu cầu một quy trình chính thức hay sự phù hợp với các tiêu chuẩn CMMI.

• Xem xét sử dụng một quy trình mẫu tối giản(minimal process template).

• Chỉnh sửa một quy trình mẫu đã có cho phù hợp với quy trình của nhóm bạn.

Security Groups and Permissions

• Tạo các security group để cấp một loạt các permission cụ thể.

• Phân chia các team member vào các security group thích hợp.

Team Projects

• Tạo một team project trên một ứng dụng nếu bạn muốn di chuyển các work item và các phần khác giữa các version(phiên bản) của ứng dụng.

• Tạo một team project trên một version nếu bạn muốn khởi động với các work item mới và các asset khác với từng version(phiên bản) của ứng dụng.

• Chỉ cấp các permission được yêu cầu trên các project assets.

• Cấu trúc source tree của bạn để hộ trợ branching.

Work Items

• Nắm bắt các kịch bản/tình huống của bạn ngay lúc bắt đầu dự án project của bạn.

• Xác định các yêu cầu Quality of Service một cách thích hợp.

• Phân chia các kịch bản scenarios thành các task quản lý, mô- đun task phát triển.

• Thiết lập từng tiêu chuẩn cơ bản cho từng task.

• Liên kết các requirement và các task cho các kịch bản.

• Sử dụng Microsoft Excel để chỉnh sửa một số lượng lớn các work item.

Areas and Iterations

• Sử dụng các area để truy nguyên nguồn gốc tốt hơn.

• Sử dụng các iteration để đại diện cho các sự kiện quan trọng ở trong project của bạn.

• Tạo một iteration riêng biệt cho các nhiệm vụ task và các kịch bản scenario không xác định.

• Xác định thời gian cho các iteration thích hợp.

Sử Dụng Các Area Để Truy Nguyên Nguồn Gốc Tốt Hơn.

Sử dụng các area trong team project của bạn để tố chức các project tasks, bugs, requirements, và các work item. Bạn cũng có thể đặt các permission trên các area để hạn chế quyền truy cập của các bộ phận khác nhau của team project của bạn.

Sử dụng các area để đại diện cho các thành phần logic hay physic , và sau đó tạo các sub-area để đại diện cho các chức năng cụ thể. Cấu trúc này giúp bạn tổ chức các work item và cải thiện tính truy nguyên(traceability) bởi các thành phần hay các chức năng.

Để tạo các area cho project của bạn

1. Trong cửa sổ Team Explorer, click vào team project của bạn.

2. Trên Team menu, trỏ đến phần Team Project Settings, và sau đó click vào Areas and Iterations.

3. Trong các Areas and Iterations dialog box, click vào Area tab.

4. Click vào Add a child node toolbar button.

5. Right-click vào new node, click Rename, và sau đó đánh vào area name bạn muốn.

6. Click vào Area node.

7. Lặp lại bước 2, 3, và 4 để tạo thêm các area và để tạo một hierarchy cho cấu trúc project structure của bạn.

Hãy cẩn thận khi tạo cấu trúc area structure quá phức tạp, trong khi các area cho phép bạn để phân vùng các work items permission, có các tạp phí liên kết với việc quản lí các permission này đối với các cây tree phức tạp. Nó cũng có thể có vấn đề về copy qua các structure/ permissions đến các Team projects khác.

Tài nguyên bổ sung

Để có thêm thông tin về sử dụng các areas, hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server" trong tài liệu này.

Sử Dụng Các Iteration Để Đại Diện Cho Các Sự Kiện Quan Trọng ở Trong Project Của Bạn

Sử dụng các iteration(lặp) để xác định xem bao nhiêu lần team của bạn sẽ lặp lại một tập các hoạt động chính cụ thể ( như là planning, implementation, hay testing) trong suốt quá trình phát triển ứng dụng. Tập các hoạt động chính này nên đại diện một sự kiện quan trọng cho project với một kết quả được định trước như là sự hoàn thành các chức năng hay các thành phần.

Để tạo một iteration

1. Trong Team Explorer, click vào team project của bạn.

2. Ở trên menu Team, trỏ đến Team Project Settings, sau đó click vào Areas and

Iterations.

3. Trong hộp thoại Areas and Iterations dialog box, click vào thẻ tab Iteration.

4. Click vào toolbar button Add a child node.

5. Right-click vào new node, click Rename, và sau đó hãy đánh tên của iteration.

6. Click vào Iteration node.

7. Lặp lại các bước 2, 3, và 4 để tạo thêm các iteration được xác định cho project của bạn.

8. Click Close.

Lưu ý: The Microsoft® Solutions Framework (MSF) cho quy trình mẫu Agile Software Development (MSF Agile) process template gồm có 3 iteration được xác định trước. Dựa trên các yêu cầu cụ thể của bạn, bạn có thể delete những iteration này, rename chúng thay vì tạo những cái mới, hay không thay đổi chúng.

Tài nguyên bổ sung

Để có thêm thông tin về sử dụng các iterations, hãy xem "Làm thế nào - Quản lý các Project trong Visual Studio Team Foundation Server" trong tài liệu này.

Tạo Một Separate Iteration Cho Các Nhiệm Vụ Task Và Các Kịch Bản Scenario Không Xác Định

Tạo một iteration riêng biệt mà bạn có thể chỉ định tất cả các kịch bản scenarios và các task mà chưa được phân định cho bất cứ iteration nào. Điều này giúp bạn dễ dàng xác định các scenarios và các task mà đang chờ được giải quyết khi lên kế hoạch các iteration của bạn.

Để tạo một separate iteration

1. Trong Team Explorer, click vào team project của bạn.

2. Ở trên Team menu, trỏ đến phần Team Project Settings, và sau đó click vào Areas and Iterations.

3. Trong hộp thoại Areas and Iterations dialog box, click vào tab Iteration.

4. Click vào toolbar button Add a child node.

5. Right-click vào new node, click Rename, và sau đó đánh tên của iteration là Iteration 999

6. Click Close.

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo các iterations, hãy xem "Làm thế nào - Quản lý các Project trong Visual Studio Team Foundation Server" trong tài liệu này.

Xác Định Thời Gian cho các Iteration Thích Hợp

Khi thiết lập team project của bạn, hãy xác định thời gian chu kì lặp(iteration cycle duration) phù hợp dựa trên kích cỡ và độ phức tạp của dự án của bạn.

Hãy nhớ các điểm chính sau khi xác định iteration cycle duration:

• Chu kì lặp(iteration cycle) nên đủ dài để cho phép các thành viên của đội nhận được những công việc làm đáng kể, và nên bao gồm ít nhất một vài kịch bản khác nhau.

Chu kì lặp(iteration cycle) nên đủ ngắn để thích nghi một cách linh hoạt với những sự thay đổi và ưu tiên.

Trong thực hành, những công việc có chu kì lặp 2 tuần dành cho hầu hết các project.

Tài nguyên bổ sung

Để có thêm thông tin về các iteration cycle duration, hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server" trong tài liệu này.
Để có thêm thông tin về iteration cycle duration, hãy xem "Chương 11 - Project Management Explained" trong tài liệu này.

Check-in Policies

• Sử dụng các check-in policies để thực thi các quy định về chất lượng code.

• Sử dụng các check-in policies để đảm bảo là các lập trình viên kết nối các work item với các check-in.

• Tạo các check-in policies để thi hành các tiêu chuẩn về code.

• Cài đặt các lưu ý để thông báo cho bạn khi các lập trình viên bỏ qua các check-in policies.

Sử Dụng Các Check-In Policies Để Thực Thi Các Quy Định Về Chất Lượng Code

Sử dụng một sự kết hợp giữa code analysis và testing policies để cải thiện chất lượng check-in cho project của bạn. Thí dụ, sử dụng các chính sách testing policy được cung cấp để đảm báo là các test cũ thể được thực thi và thông qua trước khi cho phép source được kiểm tra ở trong Microsoft Visual Studio® 2005 Team Foundation Server (TFS) source control. Bạn cũng có thể cấu hình một chính sách code analysis policy để giúp đảm bảo là phần code của bạn đáp ứng được các tiêu chuẩn chất lượng cơ bản bằng cách đảm bảo về security, performance(hiệu suất), portability(tính tiện dụng), maintainability(bảo trì), và các reliability rules(quy luật về độ tin cậy) được thông qua.

Bằng cách thi hành loại chính sách check-in policy này thêm vào các chính sách policy mà thực thi các tiêu chuẩn về code và những phần hướng dẫn, chắc chắn là phần code của bạn đáp ứng một tiêu chuẩn về chất lượng cụ thể.

Để thực hành code analysis check-in policy cho một team project

1. Ở trong Team Explorer, right-click lên team project của bạn, trỏ đến phần Team Project Settings, và sau đó click vào phần Source Control.

2. Click vào tab Check-in Policy tab, click Add, và sau đó chọn và cấu hình chính sách policy thích hợp.

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo và sử dụng một chính sách check-in policy tùy chỉnh, hãy xem "How To - Step Through Creating Custom Check-in Policies for TFS" trong tài liệu này.

Sử Dụng Các Check-In Policies Để Đảm Bảo Là Các Lập Trình Viên Kết Nối Các Work Item Với Các Check-In.

Thiết lập các Work Items check-in policy để buộc các nhà phát triển liên kết phần check-in của họ với một work item. Nếu một build bị break, điều quan trọng là bạn biết được tập các thay đổi nào được liên kết với việc build đó, và các work item nào mà những tập các thay đổi đó được liên kết đến, để bạn có thể xác định trách nhiệm của nhà phát triển nào đối với việc kiểm tra trong phần code này và nhà phát triển đang làm việc trên khu vực area nào của project.

Để cài đặt các Work Items check-in policy để buộc các nhà phát triển liên kết phần check-in của họ với một work item:

1. Ở trong Team Explorer, right-click lên team project của bạn, chọn phần Team Project Settings, và sau đó click vào phần Source Control.

2. Click vào tab Check-in Policy.

3. Click Add và sau đó chọn và cấu hình Work Item check-in policy.

Tài nguyên bổ sung

Để có thêm thông tin về các check-ins, hãy xem "How to: Check In Pending Changes" tại http://msdn2.microsoft.com/en-us/library/ms181411(VS.80).aspx
Để có thêm thông tin về các work items và các tập thay đổi changesets, hãy xem "How to: Associate Work Items with Changesets" tại http://msdn2.microsoft.com/en-us/library/ms181410(VS.80).aspx

Tạo Các Check-In Policies Để Thi Hành Các Tiêu Chuẩn Về Code

Project mà bạn đang làm việc có thể yêu cầu các tiêu chuẩn về code mà không bao gồm các chính sách phân tích code tỉnh static code analysis policy hay bằng các chính sách check-in policy đã có. Thí dụ, project của bạn có thể yêu cầu phần code của bạn không bao giờ được sử dụng kí tự tab character, hay tất cả các check-in yêu cầu các ý kiến(comment). Bạn có thể tạo mới các check-in policy để kiểm soát các kịch bản scenarios này.

Để thi hành một chính sách code analysis check-in policy cho một team project

1. Ở trong Team Explorer, right-click lên team project của bạn, trỏ đến phần Team Project Settings, và sau đó click vào phần Source Control.

2. Click vào tab Check-in Policy và sau đó click Add.

3. Ở trong hộp thoại Add Check-in Policy dialog box, hãy chọn Code Analysis và sau đó click OK.

4. Trong phần Code Analysis Policy Editor, chọn cả Enforce C/C++ Code Analysis

(/analyze) hay Enforce Code Analysis For Managed Code. Chọn cả hai nếu project của bạn có một sự kết hợp của phần code được quản lý và phần code không được quản lý.

5. Nếu bạn chọn managed code analysis, hãy cấu hình các thiết lập quy luật yêu cầu (required rule setting) cho phần managed code analysis dựa trên yêu cầu về các tiêu chuẩn code. Điều này sẽ xác định một cách chính xác là các quy luật rule nào được thi hành.

Bạn cũng có thể tạo một custom check-in policy để thực hiện các kiểm tra mà không tồn tại sẵn. Thí dụ, bạn có thể không cho phép các mẫu code pattern như là cấm các việc gọi các application programming interface (API) calls, hay bạn có thể viết một chính sách policy để thi hành các phong cách hướng dẫn code cụ thể của nhóm bạn(team's specific coding style guideline), như là vị trí của những dấu ngoặc nên được đặt với source code của bạn.

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo các check-in policies, hãy xem "How To - Create Custom Check-in Policies in Visual Studio Team Foundation Server" trong tài liệu này.

Cài Đặt Các Lưu Ý Để Thông Báo Cho Bạn Khi Các Lập Trình Viên Bỏ Qua Các Check-In Policies

Team Foundation Server Version Control không ngăn cản bạn ghi đè override một check-in policy. Tuy nhiên, bạn có thể sử dụng các bước sau để khám phá thử nếu một chính sách check-in policy đã bị override hay chưa:

1. Sử dụng Team Foundation Server Eventing Service (từ Team Foundation Core Services API) để hook các check-in event.

2. Viết một Notify method mà parse các chi tiết của tập changeset và sau đó phản ứng với nó nếu một sự override xảy ra.

Ngoài ra, bạn có thể scanmột cách thủ công changeset history để khám phá các policy override.

Tài nguyên bổ sung

Để tìm hiểu nhiều về overriding một check-in policy, hãy xem "How to: Override a Check-in Policy" tại http://msdn2.microsoft.com/en-us/library/ms245460(VS.80).aspx

Process Templates

• Sử dụng quy trình mẫu MSF Agile khi đang làm việc trên các project mà chỉ yêu cầu một quy trình ít quan trọng hay không chính thức.

• Sử dụng quy trình mẫu MSF CMMI khi làm việc trên các project yêu cầu một quy trình chính thức hay sự phù hợp với các tiêu chuẩn CMMI.

• Xem xét sử dụng một quy trình mẫu tối giản(minimal process template).

• Chỉnh sửa một quy trình mẫu đã có cho phù hợp với quy trình của nhóm bạn.

Sử Dụng Quy Trình Mẫu MSF Agile Khi Đang Làm Việc Trên Các Project Mà Chỉ Yêu Cầu Một Quy Trình Ít Quan Trọng Hay Không Chính Thức

Khi sử dụng Test-Driven Development (TDD) hay các phương pháp agile khác, bạn nên sử dụng quy trình mẫu MSF for Agile Software Development (MSF Agile) process template. Đây là một quy trình ít quan trọng cho các agile software project. Bạn nên sử dụng quy trình project này như là lựa chọn đầu tiên, nếu đặc biệt bạn không cần các chức năng cải tiến của các quy trình thêm được cung cấp bởi MSF for CMMI Software Development (MSF CMMI) process template. Bạn có thể dễ dàng chỉnh sửa quy trình mẫu của MSF Agile và thay đổi để phú hợp với các yêu cầu quy trình của bạn.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chương 11 - Project Management Explained" trong tài liệu này.
Để có thêm thông tin về MSF Agile process template, hãy xem "Chương 13 - MSF for Agile Software Development Projects" trong tài liệu này.
Để có thêm thông tin về việc tùy chỉnh các process template, hãy xem "How To - Customize a Process Template in Visual Studio Team Foundation Server" trong tài liệu này.

Sử dụng quy trình mẫu MSF CMMI khi làm việc trên các project yêu cầu một quy trình chính thức hay sự phù hợp với các tiêu chuẩn CMMI

Khi sử dụng một quy trình phát triển phần mềm chính thức(formal software development process) nhằm cải thiện các quy trình hiện có, bạn nên sử dụng các quy trình mẫu của MSF for CMMI Software Development (MS CMMI) process template.

Bạn có thể dễ dàng chỉnh sửa và thay đổi quy trình mẫu process template này cho phù hợp với các yêu cầu quy trình của bạn.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chương 11 - Project Management Explained" trong tài liệu này.
Để có thêm thông tin về tùy chỉnh template, hãy xem "How To - Customize a Process Template in Visual Studio Team Foundation Server" trong tài liệu này.

Xem xét sử dụng một quy trình mẫu tối giản(minimal process template)

Rất nhiều team không yêu cầu hỗ trợ cho tất cả những phần của một tiêu chuẩn dự án nhóm team project. Thí dụ, rất nhiều team muốn sử dụng source control portion của một team project nhưng không là Microsoft Office SharePoint® portal. Những mẫu team project template có thể được chỉnh sửa thay đổi, và có thể remove một số phần của những template mà bạn không cần. Khi bạn chỉnh sửa template, bạn sẽ cần giữ lại những phần như Group Permissions and Classifications sections; tuy nhiên, bạn có thể giữ lại hay là remove những phần khác nếu bạn thấy phù hợp.

Để tạo một minimal process template, bạn sử dụng Process Template Manager để

download phần template đến máy tính của bạn, chỉnh sửa template để remove những phần mà bạn sẽ không sử dụng, và sau đó upload trở lại template đến server.

Tài nguyên bổ sung

Để có thêm thông tin về process templates, hãy xem "Chương 13 - Process Templates Explained" trong tài liệu này.
Để có thêm thông tin về tùy chỉnh các process templates, hãy xem "How To - Customize a Process Template in Visual Studio Team Foundation Server" trong tài liệu này.
Để có thêm thông tin về tùy chỉnh các process templates, hãy xem "Customizing Process Templates" tại http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx
Để có thêm thông tin về sử dụng một minimal process template hãy xem, "How to use TFS for source control only" tại http://blogs.msdn.com/richardb/archive/2007/05/10/how-to-use-tfs-for-source-control-only.aspx

Chỉnh sửa một quy trình mẫu đã có cho phù hợp với quy trình của nhóm bạn

Dự án project mà bạn đang làm việc có thể không phù hợp với các quy trình mẫu out-of-box process templates được cung cấp với Microsoft Visual Studio Team System (VSTS). Bạn có thể cần một loại work item khác, hay bạn có thể sử dụng một phương pháp quy trình hoàn toàn khác. Trong trường hợp này, bạn nên thay đổi các mẫu quy trình đã có. Hãy chọn các quy trình mẫu process template mà hầu như đáp ứng được tốt nhất các yêu cầu quy trình của bạn và sau đó chỉnh sửa các template nếu cần thiết.

Những phần sau của các quy trình mẫu process template thường cần được chỉnh sửa:

• Groups and Permissions

• Work Item Types

• Source Control Check-in Notes and Policies

• Areas and Iterations

• Reports

• Team Portal

• Process Guidance

Tài nguyên bổ sung

Để có thêm thông tin về process templates, hãy xem "Chương 13 - Process Template Explained" trong tài liệu này.
Để có thêm thông tin về tùy chỉnh các template, hãy xem "How To - Customize a Process Template in Visual Studio Team Foundation Server" trong tài liệu này.

Security Groups and Permissions

• Tạo các security group để cấp một loạt các permission cụ thể.

• Phân chia các team member vào các security group thích hợp.

Tạo các security group để cấp một loạt các permission cụ thể

Khi bạn tạo một project trong Team Foundation Server, 4 nhóm mặc định được tạo cho project đó bất kể lựa chọn của bạn về process template. Mặc định, từng group có một tập các permission được định nghĩa cho việc những gì mà các thành viên của các nhóm đó được phép làm. Bốn nhóm đó là:

• Project Administrator

• Contributor

• Reader

• Build Services.

Bạn có thể tạo các security group cho team project của bạn đáp ứng tốt hơn các yêu cầu security của tổ chức của bạn. Tạo một security group là một cách hiệu quả để cấp một tập các permission cụ thể đến một group các user trên team project của bạn. Hãy chắc là bạn chỉ cho phép các permission cần thiết tối thiểu cho group, và chỉ thêm các user hay các group mà phải thuộc về team project group mới.

Ngoài ra hãy sử dụng các hướng dẫn sau đây:

Không thay đổi các permission trên các group mặc định (hoặc nếu bạn làm, hãy làm trên mọi project với cùng một cách giống nhau)
Sử dụng các Active Directory (AD) group chỉ cho các thành viên trên level server.
Sử dụng các TFS group cho các thiết lập permission(hơn là các AD group)
Đừng bao giờ deny bất cứ điều gì (luôn luôn deny nghĩa là phân vùng mà bạn sử dụng sẽ ít hơn rất nhiều); hãy chắc là nguyên nhân của bạn là đúng đắn khi bạn thực hiện điều gì đó.

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo các security groups, hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server" trong tài liệu này.
Để có thêm thông tin về TFS permissions, hãy xem "Team Foundation Server Permissions" tại http://msdn2.microsoft.com/en-us/library/ms252587(VS.80).aspx

Phân chia các team member vào các security group thích hợp

Hãy xác định các team member sẽ làm việc trên project và những vai trò của họ, và phân chia những team member này vào TFS bằng cách sử dụng các team project group ,các server-level group đã có, hay các custom security group mà bạn tạo ra.

Khi phân chia các member vào một security group, chỉ phân chia các member mà cần các permission có sẵn cho security group đó. Nếu cần thiết, bạn có thể tạo các custom security group với các security permission phù hợp và sau đó phân chia các uservào các security group đó.

Tài nguyên bổ sung

Để có thêm thông tin về các security group, hãy xem "How To - Manage Projects in Visual Studio Team Foundation Server" trong tài liệu này.

Hướng dẫn: Team Build

Nguyễn Thị Như Quỳnh — Tue, 15 Dec 2009 05:37:53 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/15/2009 1:37:53 PM

Hướng dẫn: Team Build

Đây là phần hướng dẫn sẽ gồm các mục sau:

Các mục

Strategy

Sử dụng một scheduled build để tạo ra các regular builds.
Sử dụng một Continuous Integration (CI) build để nhận các feedback một cách nhanh chóng trên các check-ins.
Sử dụng một rolling build nếu các CI builds ảnh hưởng bất lợi đến hiệu suất build server performance.
Sử dụng branching để giảm các build breaks.
Sử dụng check-in policies để cải thiện chất lượng check-in.
Sử dụng build notification alerts để tìm hiểu khi nào các build hoàn thành.

Branching

Sử dụng Team Build Types mới khi tạo một phần branch.
Chỉnh sửa các path để giải quyết trong TFSBuild.proj files, khi tạo một branch hoàn chỉnh.

Continuous Integration Builds

Sử dụng một CI build để nhận nhanh chóng các feedback trên các check-in.
Sử dụng một rolling build nếu các CI build có ảnh hưởng xấu đến hiệu suất build serverperformance.
Hãy đảm bảo là tần số của các rolling build của bạn thường ít hơn các build times.

Customization

Sử dụng một custom post-build step để build một installer project.
Sử dụng MS Build Toolkit Extras để build các Microsoft .NET 1.1 applications.
Sử dụng TFSBuild.proj để chỉnh sửa các build của bạn.
Sử dụng một custom pre-build step để build một project có phụ thuộc đến các team project khác.

Deployment

Trên các team lớn, install các build services trên một separate server .riêng.

Performance

Sử dụng các incremental builds để cải thiện hiệu suất.
Tránh việc đồng bộ hóa các folder dự phòng trong các build của bạn.
Sử dụng các workspaces để tránh check out các file và project không mong muốn khi đang thực hiện một Team Build.
Xem xét sử dụng các multiple build machines để nâng cao hiệu suất.

Projects

Tránh các phụ thuộc qua lại giữa các team project với nhau.
Sử dụng các project references thay vì các file references.
Sử dụng Web Deployment Project cho các Web applications.
Sử dụng một single-solution strategy nếu bạn đang làm việc trên một team project nhỏ.
Sử dụng một partitioned-solution strategy nếu bạn đang làm việc trên một team project lớn với nhiều project con độc lập nhau.
Sử dụng một multiple-solution strategy nếu bạn đang làm việc trên một team project rất lớn mà yêu cầu đến hàng chục project con độc lập nhau.

Scheduled Builds

Sử dụng một scheduled build để tạo các regular builds.

Test-Driven Development

Run code analysis trên từng build.
Run automated tests trên từng build.
Xem xét gán các build thành fail khi các automated test bị fail.

Work Items

Sử dụng các work items để theo dõi các build breaks.

Strategy

• Sử dụng một scheduled build để tạo các regular builds.

• Sử dụng CI build để lấy nhanh chóng các feedback trên các check-in.

• Sử dụng một rolling build nếu các CI build có tác động xấu đến năng suất của serverperformance.

• Sử dụng branching để giảm thiểu các build breaks.

• Sử dụng các check-in policy để cải thiện chất lượng check-in quality.

• Sử dụng build notification alerts để tìm hiểu khi nào các build được hoàn thành.

Sử dụng một scheduled build để tạo các regular builds

Sử dụng một scheduled build để tạo ra các builds một cách thường xuyên, dự báo các khoảng cách.

Nhìn chung, các build cung cấp cho test team của bạn và những nhóm khác để tin cậy và nên thực hiện sẵn tại một mức thời gian cố định, để các feedback trên các build có thể được thu thập một cách kịp thời.

The Team Build feature in Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) không support các scheduled build từ giao diện người dùng(user interface). Thay vào đó, bạn có thể sử dụng Microsoft Windows® Task Scheduler để chạy TFSBuild command-line utility để bắt đầu các build tại một thời điểm xác định trước.

Để tạo một scheduled build

1. Tạo một TFSBuild command line như sau:

TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>

2. Đặt các command line trong một batch file.

3. Tạo một Windows Scheduled Task để chạy các batch file tại khoảng thời gian mong muốn của bạn.

Tài nguyên bổ sung

Để có thêm thông tin về thiết lập các scheduled build với Team Build, hãy xem"Chương 9: Cài đặt một Scheduled Build với Team Build" trong tài liệu này.
Để có thêm thông tin về thiết lập các scheduled build với TFS, hãy xem "Làm thế nào - Cài đặt một Scheduled Build trong Visual Studio Team Foundation Server" trong tài liệu này.

Sử dụng CI build để lấy nhanh chóng các feedback trên các check-in

Bạn nên sử dụng các CI build để cung cấp cho nhóm phát triển của bạn các feedback nhanh về bất kì sự thay đổi breaking change nào và về chất lượng của các build sau mỗi check-in. Điều này giúp cho các nhóm phát triển sữa chữa các vấn đề build một cách nhanh chóng và có thể được sử dụng như là một tool để cải thiện chất lượng code của bạn.

Mặc dù Team Foundation Server 2005 không cung cấp một CI solution out of box, nó đã cung cấp framework cho bạn để thực thi CI build solution của riêng bạn.

Để có thêm thông tin về thiết lập một CI build với TFS, hãy xem "How To - Set Up a Continuous Integration Build in Visual Studio Team Foundation Server." Đề tài How To article này sử dụng the solution được cung cấp bởi the Microsoft Visual Studio Team System (VSTS) development team. The solution sẽ cài đặt một Web service chạy bên dưới một account that đã truy cập đến TFS server. Team Foundation Server có thể send một e-mail message hay call một Web service khi các event cụ thể xảy ra. Cơ chế event này được sử dụng bởi CI solution để đăng kí một Web service với CheckinEvent event, để bất cứ khi nào một check-in xảy ra, the Web service khởi động một Team Build.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chapter 8: Setting Up a Continuous Integration Build with Team Build" trong tài liệu này.
Để có thêm thông tin về cài đặt một CI build, hãy xem "How To - Set Up a Scheduled Build with Visual Studio Team Foundation Server" trong tài liệu này.
Để có thêm thông tin về làm cách nào để sử dụng VSTS CI solution, hãy xem "Continuous Integration Using Team Foundation Build" tại http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx
Để download the VSTS CI solution MSI, hãy đến http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi
Để có thêm thông tin về agile development và CI in TFS, hãy xem "Extend Team Foundation Server To Enable Continuous Integration" tại http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx

Sử dụng một rolling build nếu các CI build có tác động xấu đến hiệu suất của serverperformance.

Build ngay lập tức ngay sau khi mọi check-in là chiến thuật(strategy) thuật CI đơn giản nhất và nhìn chung cung cấp cho bạn hầu hết các feedback nhanh chóng. Tuy nhiên, nếu các check-in xảy ra một cách nhanh chóng đủ để làm quá tải(overwhelm) tải build server của bạn, thì bạn nên sử dụng một phương pháp rolling buildapproach nơi bạn build sau một số lần các check-in cụ thể hay sau một số giai đoạn thời gian. Để quyết định nếu bạn cần sử dụng một rolling build, thì hãy xác định những điều sau:

Độ dài của Team Build của bạn theo phút
Tần số trung bình của các check-in theo phút.
Time window trong suốt các check-in thường xuyên xảy ra

Nếu chiều dài build dài hơn tần số trung bình của các check-in, các build của bạn sẽ chạy liên tục bởi vì build đầu tiên sẽ hoàn thành trước khi check-in tiếp theo xảy ra, là check-in sẽ bắt đầu một build khác. Nếu các check-in tiếp tục xảy ra trước mỗi build được hoàn thành, điều này ảnh hưởng đến hiệu suất của build server và sẽ block các build khác (như là các scheduled build) đang được bắt đầu. Xem lại cửa sổ thời gian time window trong suốt khi quá trình xảy ra các check-in xảy ra một cách thường xuyên và xác định nếu các CI build sẽ ảnh hưởng đến sự phân phối của các scheduled build hay các Team Builds quan trọng khác.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chapter "Chương 8 - Setting Up a Thiết lập một Continuous Integration Build with với Team Build" trong tài liệu này.

Sử dụng branching để giảm thiểu các build breaks

Để giúp tránh các build break, bạn nên sử dụng một Development branch cho các hoạt động phát triển và một Main branch cho integration build của bạn.

Sau đây là một thí dụ về cấu trúc branch phải ra sao sau khi bạn tạo một Development branch:

Development - Development Branch

o Source

Main - Integration Branch

o Source

o Other Assets folders

Hãy nhớ đến những lời đề nghị sau khi bạn làm việc với một nhánh release branch:

Khi branch. Nếu bạn đang tạo các daily build và đang có vấn đề với build stabilization và integration, bạn nên tạo cả một main và một development branch để đảm bảo là các daily build của bạn lớn hơn so với dự đoán. Bạn cũng có thể muốn xem xét kĩ lưỡng nhiều hơn các chính sách về check-in policy để cải thiện chất lượng của các check-in.
Khi không branch. Nếu bạn chỉ tạo các CI build, hay các daily build của bạn được dự đoán đã ổn định, bạn không cần phải thêm chi phí của các integration branch.
Permissions trên branch:

o The Main branch permissions nên được read/write cho các nhà phát triển chịu trách nhiệm về merging và integration, nhưng read-only cho tất cả mọi người khác.

o The Dev branch permissions nên là read/write cho everyone.

Build frequency trong branch:

o Daily builds trên Main branch.

o CI builds trên Dev branch.

Testing focus on branch:

o Thực hiện kiểm thử tích hợp, hiệu suất và bảo mật(integration, performance, và security testing) trên Main branch.

o Thực thi các kiểm thử chức năng và phản hồi nhanh(feature and quick feedback testing) trên Dev branch.

Sử dụng Main branch như là một staging area cho việc tích hợp các thay đổi(integrating change) mà cần được kiểm tra trong development branch. Thực hiện tất cả các hoạt động phát triển(active development) trong Dev branch, và tích hợp các non-breaking changes trong Main branch.

Tài nguyên bổ sung

Để có thêm thông tin về xác định một branching and merging strategy, hãy xem "Chapter 5 - Defining Your Branching and Merging Strategy" trong tài liệu này.
Để có sự giới thiệu về branching and merging, hãy xem "Branching and Merging Primer" tại http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx
Để có thêm thông tin về branching, hãy xem "How to: Branch Files and Folders" tại http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx
Để có thêm thông tin về merging, hãy xem "How to: Merge Files and Folders" tại http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx
Đối với các miêu tả thêm về làm cách nào để branch và merge trong Visual Studio 2005, hãy xem "Branching and Merging Team Foundation Source Control" tại http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx

Sử dụng các check-in policy để cải thiện chất lượng check-in quality

Bạn nên sử dụng một sự kết hợp code analysis policy với các testing policy để cải thiện chất lượng check-in quality. Thí dụ, sử dụng các chính sách testing policy được cung cấp để đảm bảo là các test cụ thể được thực thi và được thông qua trước khi cho phép source được kiểm tra trong TFS source control. Bạn cũng có thể cấu hình một chính sách code analysis policy để giúp đảm bảo là code của bạn đáp ứng một số tiêu chuẩn chất lượng bằng cách đảm bảo các quy tắc về security, performance, portability, maintainability, và reliability rules được thông qua.

Bằng cách thi hành các loại chính sách check-in policy này, thêm vào các policy mà thi hành các chuẩn code và hướng dẫn, bạn có thể test phần code của bạn dựa vào các vấn đề chất lượng code cụ thể.

Để thi hành một code analysis check-in policy cho một team project, bạn click phải lên team project của bạn trong Team Explorer, trỏ đến Team Project Settings, và sau đó click vào Source Control. Click vào tab Check-in Policy , click Add, và sau đó chọn và cấu hình chính sách phù hợp.

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo và sử dụng một custom check-in policy, hãy xem "How To - Step Through Creating Custom Check-in Policies for TFS" trong tài liệu này.
Để tìm hiểu về làm cách nào để tùy chỉnh một check-in policy, hãy xem "Walkthrough: Customizing Check-in Policies and Notes" tại http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx
Để xem sample code mà sẽ không cho phép chọn các pattern trên check-in, hãy xem "Checkin Policy to Disallow Certain Patterns" tại http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx
Để xem sample code sẽ thi hành các comment trên check-in, hãy xem "Sample Checkin Policy: Make Sure the Comment Isn't Empty" tại http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx
Để tìm hiểu làm thế nào để đăng kí mới một check-in policy, hãy xem "I've Made a New Check-In Policy! How Do I Add It?" tại http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx

Sử dụng build notification alerts để tìm hiểu khi nào các build được hoàn thành

Để theo dõi build process của bạn, bạn có thể tạo các alert mà gửi e-mail messages đến cho bạn hay các người khác khi một build được hoàn thành.

Điều này quan trọng vì nó cung cấp xoay vòng nhanh chóng giữa các nhóm. Thí dụ, nếu test team được thông báo qua e-mail của một build đã hoàn thành, chúng có thể khởi động test pass của chúng mà không phải đợi các hướng dẫn sử dụng.

Tài nguyên bổ sung

Để có thêm thông tin về build notifications, hãy xem "How to: Receive Build Notification E-Mail" tại http://msdn2.microsoft.com/en-us/library/ms181725(VS.80).aspx
Để có thêm thông tin về build notifications, hãy xem "How to: Add or Edit Alerts" tại http://msdn2.microsoft.com/en-us/library/ms181335(VS.80).aspx

Branching

• Sử dụng các Team Build Types mới khi tạo một partial branch.

• Chỉnh sửa các path để giải quyết trong TFSBuild.proj files, khi tạo một complete branch.

Sử dụng các Team Build Types mới khi tạo một partial branch

Khi bạn tạo một branch mà chứa một tập con các solution trong team project của bạn, bạn cần phải tạo mới các build type để build thành công.

Có hai loại partial branches:

1. Một partial branch không bao gồm branching của bất cứ loại build type nào. Điều này sẽ xảy ra trong một team project, và sẽ là branch solution và các source file đơn giản nhưng sẽ không branch bất kì TeamBuildTypes folder nào trong các folder mới.

2. Một partial branch bao gồm branching của các loại build type. This Điều này sẽ xảy ra trong một team project, và sẽ branch một số subfolders của TeamBuildTypes (tức là, các loại build type) ngoài ra để các folders chứa các solution và source file liên quan nhau.

Nếu bạn tạo một partial branch mà không bao gồm Team Build Types tất cả của các Team Build đã có sẽ tiếp tục làm việc, nhưng bạn sẽ càn tạo mới Team Build Type nếu bạn muốn build branch. Tạo mới các build types bằng cách sử dụng Team Build Wizard để build code trong các branch mới. Những loại build type mới này sẽ trỏ đến branch location cũng có thể trỏ đến parent location cho bất kì solution nào mà phải được bao gồm trong build nhưng không được branch.

Nếu bạn tạo một partial branch gồm có các Team Build Types, các build type mà được copy qua branch sẽ chỉ đến các original, parent branch locations và vì thế mà sẽ không cho phép bạn build branch mới. Chỉnh sửa các branched build types để chúng chỉ đến các branched code location mới.

Tài nguyên bổ sung

Để có thêm thông tin về làm thế nào để update các build type của bạn, hãy xem "How to: Update Build Types on Branched Team Projects" tại http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx

Chỉnh sửa các path để giải quyết trong TFSBuild.proj files, khi tạo một complete branch

Khi bạn tạo mới một branch, gồm có các Team Build Types, các đường dẫn path trong các build types vẫn còn trỏ đến các location trước. Để cho các build làm việc trên branch mới, bạn phải update các path trong các build type project file để chúng reference đến các path location mới tạo sau khi branch hoạt động.

Khi bạn tạo một full branch, bạn cũng branch các build type. Các build types chứa các reference đến các folder từ các original source control tree. Để có những build type này refer đến các branch folders, bạn phải edit các folder references ở trong những file này.

Để thực thi update, check out các build type từ các branch mà bạn muốn chỉnh sửa modify, áp dụng các update, và sau đó commit các thay đổi đến các branch.

Tài nguyên bổ sung

Để có thêm thông tin về làm thế nào để update các build type, hãy xem "How to: Update Build Types on Branched Team Projects" tại http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx

Check-in Policies

• Sử dụng các check-in policies để nâng cao check-in quality.

• Sử dụng check-in policies để liên kết các work items với việc build.

Sử dụng các check-in policies để nâng cao check-in quality

Sử dụng sự liên kết giữa các chính sách phân tích và kiểm thử code(code analysis and testing policies) để nâng cao chất lượng của các check-in(check-in quality). Thí dụ, sử dụng các chính sách kiểm thử được cung cấp(supplied testing policy) để đảm bảo là các specific test được thực hiện và thông qua trước khi cho phép các source được kiểm tra ở trong TFS source control. Bạn cũng có thể cấu hình một code analysis policy để giúp đảm bảo là code của bạn đáp ứng được tiêu chuẩn chất lượng nhất định bằng việc đảm bảo về khía cạnh security(bảo mật), performance(hiệu suất), portability(tính linh động), maintainability(bảo trì), và các nguyên tắc tin cậy(reliability rules) được thông qua.

Bằng các sử dụng loại check-in policy này thêm vào các policy mà được thi hành các tiêu chuẩn và hướng dẫn code, bạn có thể test phần code của bạn dựa trên các vấn đề chất lượng code cụ thể(specific code quality issues).

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo và sử dụng một custom check-in policy, hãy xem "How To: Step Through Creating Custom Check-in Policies for TFS" trong tài liệu này.
Để tìm hiểu làm cách nào để tùy chỉnh một check-in policy, hãy xem "Walkthrough: Customizing Check-in Policies and Notes" tại http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx
Để xem các phần code đơn giản mà sẽ disallow các selected patterns trong check-in, hãy xem "Check-in Policy to Disallow Certain Patterns" tại http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx

• Để xem các phần code đơn giản mà sẽ enforce các comment trên check-in, hãy xem "Sample Check-in Policy: Make Sure the Comment Isn't Empty" tại http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx

Để tìm hiểu làm thế nào để đăng kí một check-in policy mới, hãy xem "I've Made a New Check-In Policy! How Do I Add It?" tại http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx

Sử dụng check-in policies để liên kết các work items với việc build

Thiết lập các Work Items check-in policy để buộc các lập trình viên phải liên kết các check-in của họ với một work item.

Nếu một build bị break, điều quan trọng là bạn phải biết được tập các thay đổi(change set) nào liên quan đến build này và các work item nào liên quan đến tập các thay đổi(change set) đó. Bằng sự hiểu biết này, bạn có thể xác định được lập trình viên nào chịu trách nhiệm kiểm tra trong phần code bị thay đổi và area của dự án mà anh ta hay cô ta đang làm việc.

Đối với một build được liên kết với một tập các work item đã hoàn thành, mỗi check-in phải được liên kết với một work item. Những check-in này được tiêu biểu như các change set liên kết với một build, và có thể theo dõi từ build đến change set đến work item.

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo và sử dụng một custom check-in policy, see "How To: Step Through Creating Custom Check-in Policies for TFS" trong tài liệu này.
Để tìm hiểu làm thế nào để tùy chỉnh một check-in policy, see "Walkthrough: Customizing check-in Policies and Notes" tại

http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx

Continuous Integration Builds

• Sử dụng một CI build để lấy các feedback nhanh chóng trên các check-ins.

• Sử dụng một rolling build nếu các CI build có ảnh hưởng không tốt đến hiệu suất của build server performance.

• Đảm bảo là tần số(frequency) của các rolling build của bạn thường nhỏ hơn số build times.

Sử dụng một CI build để lấy các feedback nhanh chóng trên các check-ins

Bạn nên sử dụng các Continuous Integration builds để cung cấp cho development team của bạn các rapid feedback trên bất kì breaking change nào và chất lượng của build sau mỗi check-in. Điều này giúp các development team sữa các vấn đề thiết kế(build issues) một cách kịp thời và có thể được sử dụng như một công cụ tool để cải thiện chất lượng code của bạn.

Mặc dù Visual Studio 2005 Team Foundation Server không cung cấp một CI solution out of the box, nó đã cung cấp framework cho bạn để thực thi CI build solution của bạn.

Để có thêm thông tin về cài đặt một CI build với TFS, hãy xem "How To: Set Up a Continuous Integration Build in Visual Studio Team Foundation Server." Đề tài How To article sử dụng solution được cung cấp bởi VSTS development team. The solution install một Web service mà chạy bên dưới một account mà account đó đã truy cập đến TFS server. Team Foundation Server có thể send một e-mail message hay gọi một Web service khi các event cụ thể xảy ra. Cơ chế event này được sử dụng bởi CI solution để đăng kí một Web service với CheckinEvent event, để bất cứ khi nào một check-in xảy ra, Web service khởi động một Team Build.

Tài nguyên bổ sung

Để có thêm các thông tin về các CI build, hãy xem "Chapter 8 - Setting Up a Continuous Integration Build with Team Build" trong tài liệu này.
Để có thêm các thông tin về cài đặt một CI build, hãy xem "How To - Set Up a Continuous Integration Build with Visual Studio Team Foundation Server" trong tài liệu này
Để có thêm các thông tin về làm thế nào để sử dụng VSTS CI solution, hãy xem "Continuous Integration Using Team Foundation Build" tại http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx
Để download the Visual Studio Team System CI solution MSI, hãy đến http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi
Để có thêm các thông tin về agile development và CI trong TFS, hãy xem "Extend Team Foundation Server to Enable Continuous Integration" tại http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx

Sử dụng một rolling build nếu các CI build có ảnh hưởng không tốt đến hiệu suất của build server performance

Building ngay sau khi tất cả các check-in xảy ra là chiến lược CI đơn giản nhất và thường sẽ cho bạn hầu hết các feedback nhanh. Tuy nhiên, nếu các check-in xảy ra một cách nhanh chóng đủ để làm tràn build server của bạn, bạn nên sử dụng một phương pháp rolling build ở nơi bạn build sau khi một số các check-in cụ thể hay sau một giai đoạn thời gian cụ thể. Để quyết định nếu bạn cần sử dụng một rolling build, hãy xác định các điều sau:

Chiều dài của Team Build được tính bằng phút.
Tần số trung bình của các check-in được tính bằng phút.
Time window during which frequent check-ins occur

Nếu độ dài của các build lâu hơn tần số trung bình của các check-in, các build của bạn sẽ chạy liên tục bởi vì build đầu tiên sẽ không hoàn thành trước khi check-in tiếp theo xảy ra, sẽ khởi động build khác. Nếu các check-in tiếp tục xảy ra trước mỗi build hoàn thành, nó sẽ ảnh hưởng đến hiệu suất của build server của bạn và sẽ trì hoãn các build khác, như là các scheduled builds. Xem lại time window trong suốt thời gian các check-in xảy ra và xác định nếu các CI build ảnh hưởng đến sự phân phối của các scheduled build hay các Team Build quan trọng khác.

Tài nguyên bổ sung

Để có thêm thông tin về cài đặt các CI build, hãy xem "Chapter 8 - Setting Up an Continuous Integration Build with Team Build" trong tài liệu này.

Hãy chắc là tần số của các Rolling Build của bạn nhỏ hơn số lần Build Times

Xác định khoảng thời gian rolling build để đảm bảo cho một quy trình build process hiệu quả thì quan trọng. Nếu tần số của các rolling build nhỏ hơn thời gian để hoàn thành một build, nó đảm bảo là build machine của bạn sẽ sẵn sàng cho các build type khác ở giữa các khoảng thời gian rolling build của bạn.

Để xác định khoảng thời gian rolling build lý tưởng, hãy chia tần số trung bình của các check-in theo độ dài của build của bạn. Ví dụ, nếu bạn có một build mà mất 10 phút và bạn trung bình một check-in là 5 phút, bạn có thể gán một khoảng thời gian check-in của hai check-in và một khoảng thời gian chờ là 10 phút. Điều này đảm bảo là các build sẽ được hoàn thành trước khi build kế tiếp được kích hoạt. Nếu bạn nhận thấy là có việc load quá tải trên build server của bạn, bạn có thể tăng các giá trị này.

Tài nguyên bổ sung

Để có thêm thông tin về các CI build, hãy xem "Chapter 8 - Setting Up a Continuous Integration Build with Team Build" trong tài liệu này.

Hướng dẫn: Team Build

Nguyễn Thị Như Quỳnh — Mon, 14 Dec 2009 20:31:05 GMT

Revision 1 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/15/2009 4:31:05 AM

Đây là phần hướng dẫn sẽ gồm các mục sau:

Các mục

Strategy

Sử dụng một scheduled build để tạo ra các regular builds.
Sử dụng một Continuous Integration (CI) build để nhận các feedback một cách nhanh chóng trên các check-ins.
Sử dụng một rolling build nếu các CI builds ảnh hưởng bất lợi đến build server performance.
Sử dụng branching để giảm các build breaks.
Sử dụng check-in policies để cải thiện chất lượng check-in.
Sử dụng build notification alerts để tìm hiểu khi nào các build hoàn thành.

Branching

Sử dụng Team Build Types mới khi tạo một phần branch.
Chỉnh sửa các path để giải quyết trong TFSBuild.proj files, khi tạo một branch hoàn chỉnh.

Continuous Integration Builds

Sử dụng một CI build để nhận nhanh chóng các feedback trên các check-in.
Sử dụng một rolling build nếu các CI build có ảnh hưởng xấu đến build server performance.
Hãy đảm bảo là tần số của các rolling build của bạn thường ít hơn các build times.

Customization

Sử dụng một custom post-build step để build một installer project.
Sử dụng MS Build Toolkit Extras để build các Microsoft .NET 1.1 applications.
Sử dụng TFSBuild.proj để chỉnh sửa các build của bạn.
Sử dụng một custom pre-build step để build một project có phụ thuộc đến các team project khác.

Deployment

Trên các team lớn, install các build services trên một separate server.

Performance

Sử dụng các incremental builds để cải thiện hiệu suất.
Tránh việc đồng bộ hóa các folder dự phòng trong các build của bạn.
Sử dụng các workspaces để tránh check out các file và project không mong muốn khi đang thực hiện một Team Build.
Xem xét sử dụng các multiple build machines để nâng cao hiệu suất.

Projects

Tránh các phụ thuộc qua lại giữa các team project với nhau.
Sử dụng các project references thay vì các file references.
Sử dụng Web Deployment Project cho các Web applications.
Sử dụng một single-solution strategy nếu bạn đang làm việc trên một team project nhỏ.
Sử dụng một partitioned-solution strategy nếu bạn đang làm việc trên một team project lớn với nhiều project con độc lập nhau.
Sử dụng một multiple-solution strategy nếu bạn đang làm việc trên một team project rất lớn mà yêu cầu đến hàng chục project con độc lập nhau.

Scheduled Builds

Sử dụng một scheduled build để tạo các regular builds.

Test-Driven Development

Run code analysis trên từng build.
Run automated tests trên từng build.
Xem xét gán các build thành fail khi các automated test bị fail.

Work Items

Sử dụng các work items để theo dõi các build breaks.

Strategy

• Sử dụng một scheduled build để tạo các regular builds.

• Sử dụng CI build để lấy nhanh chóng các feedback trên các check-in.

• Sử dụng một rolling build nếu các CI build có tác động xấu đến server performance.

• Sử dụng branching để giảm thiểu các build breaks.

• Sử dụng các check-in policy để cải thiện chất lượng check-in quality.

• Sử dụng build notification alerts để tìm hiểu khi nào các build được hoàn thành.

Sử dụng một scheduled build để tạo các regular builds

Sử dụng một scheduled build để tạo ra các builds một cách thường xuyên, dự báo các khoảng cách.

Để tạo một scheduled build

1. Tạo một TFSBuild command line như sau:

TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>

2. Đặt các command line trong một batch file.

3. Tạo một Windows Scheduled Task để chạy các batch file tại khoảng thời gian mong muốn của bạn.

Tài nguyên bổ sung

Để có thêm thông tin về thiết lập các scheduled build với Team Build, hãy xem"Chương 9: Cài đặt một Scheduled Build với Team Build" trong tài liệu này.
Để có thêm thông tin về thiết lập các scheduled build với TFS, hãy xem "Làm thế nào - Cài đặt một Scheduled Build trong Visual Studio Team Foundation Server" trong tài liệu này.

Sử dụng CI build để lấy nhanh chóng các feedback trên các check-in

Mặc dù Team Foundation Server 2005 không cung cấp một CI solution out of box, nó đã cung cấp framework cho bạn để thực thi CI build solution của riêng bạn.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chapter 8: Setting Up a Continuous Integration Build with Team Build" trong tài liệu này.
Để có thêm thông tin về cài đặt một CI build, hãy xem "How To - Set Up a Scheduled Build with Visual Studio Team Foundation Server" trong tài liệu này.
Để có thêm thông tin về làm cách nào để sử dụng VSTS CI solution, hãy xem "Continuous Integration Using Team Foundation Build" tại http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx
Để download the VSTS CI solution MSI, hãy đến http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi
Để có thêm thông tin về agile development và CI in TFS, hãy xem "Extend Team Foundation Server To Enable Continuous Integration" tại http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx

Sử dụng một rolling build nếu các CI build có tác động xấu đến server performance

Build ngay lập tức ngay sau khi mọi check-in là chiến thuật(strategy) CI đơn giản nhất và nhìn chung cung cấp cho bạn hầu hết các feedback nhanh chóng. Tuy nhiên, nếu các check-in xảy ra một cách nhanh chóng đủ để làm quá tải(overwhelm) build server của bạn, bạn nên sử dụng một phương pháp rolling build approach nơi bạn build sau một số các check-in cụ thể hay sau một số giai đoạn thời gian. Để quyết định nếu bạn cần sử dụng một rolling build, hãy xác định những điều sau:

Độ dài của Team Build của bạn theo phút
Tần số trung bình của các check-in theo phút.
Time window trong suốt các check-in thường xuyên xảy ra

Nếu chiều dài build dài hơn tần số trung bình của các check-in, các build của bạn sẽ chạy liên tục bởi vì build đầu tiên sẽ hoàn thành trước khi check-in tiếp theo xảy ra, là check-in sẽ bắt đầu một build khác. Nếu các check-in tiếp tục xảy ra trước mỗi build được hoàn thành, điều này ảnh hưởng đến hiệu suất của build server và sẽ block các build khác (như là các scheduled build) đang được bắt đầu. Xem lại cửa sổ time window trong suốt khi các check-in xảy ra một cách thường xuyên và xác định nếu các CI build sẽ ảnh hưởng đến sự phân phối của các scheduled build hay các Team Builds quan trọng khác.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chapter 8 - Setting Up a Continuous Integration Build with Team Build" trong tài liệu này.

Sử dụng branching để giảm thiểu các build breaks

Để giúp tránh các build break, bạn nên sử dụng một Development branch cho các hoạt động phát triển và một Main branch cho integration build của bạn.

Sau đây là một thí dụ về cấu trúc branch phải ra sao sau khi bạn tạo một Development branch:

Development - Development Branch

o Source

Main - Integration Branch

o Source

o Other Assets folders

Hãy nhớ đến những lời đề nghị sau khi bạn làm việc với một nhánh release branch:

Khi branch. Nếu bạn đang tạo các daily build và đang có vấn đề với build stabilization và integration, bạn nên tạo cả một main và một development branch để đảm bảo là các daily build của bạn lớn hơn so với dự đoán. Bạn cũng có thể muốn xem xét kĩ lưỡng nhiều hơn các chính sách về check-in policy để cải thiện chất lượng của các check-in.
Khi không branch. Nếu bạn chỉ tạo các CI build, hay các daily build của bạn được dự đoán đã ổn định, bạn không cần phải thêm chi phí của các integration branch.
Permissions trên branch:

o The Main branch permissions nên được read/write cho các nhà phát triển chịu trách nhiệm về merging và integration, nhưng read-only cho tất cả mọi người khác.

o The Dev branch permissions nên là read/write cho everyone.

Build frequency trong branch:

o Daily builds trên Main branch.

o CI builds trên Dev branch.

Testing focus on branch:

o Thực hiện kiểm thử tích hợp, hiệu suất và bảo mật(integration, performance, và security testing) trên Main branch.

o Thực thi các kiểm thử chức năng và phản hồi nhanh(feature and quick feedback testing) trên Dev branch.

Tài nguyên bổ sung

Để có thêm thông tin về xác định một branching and merging strategy, hãy xem "Chapter 5 - Defining Your Branching and Merging Strategy" trong tài liệu này.
Để có sự giới thiệu về branching and merging, hãy xem "Branching and Merging Primer" tại http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx
Để có thêm thông tin về branching, hãy xem "How to: Branch Files and Folders" tại http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx
Để có thêm thông tin về merging, hãy xem "How to: Merge Files and Folders" tại http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx
Đối với các miêu tả thêm về làm cách nào để branch và merge trong Visual Studio 2005, hãy xem "Branching and Merging Team Foundation Source Control" tại http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx

Sử dụng các check-in policy để cải thiện chất lượng check-in quality

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo và sử dụng một custom check-in policy, hãy xem "How To - Step Through Creating Custom Check-in Policies for TFS" trong tài liệu này.
Để tìm hiểu về làm cách nào để tùy chỉnh một check-in policy, hãy xem "Walkthrough: Customizing Check-in Policies and Notes" tại http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx
Để xem sample code mà sẽ không cho phép chọn các pattern trên check-in, hãy xem "Checkin Policy to Disallow Certain Patterns" tại http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx
Để xem sample code sẽ thi hành các comment trên check-in, hãy xem "Sample Checkin Policy: Make Sure the Comment Isn't Empty" tại http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx
Để tìm hiểu làm thế nào để đăng kí mới một check-in policy, hãy xem "I've Made a New Check-In Policy! How Do I Add It?" tại http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx

Sử dụng build notification alerts để tìm hiểu khi nào các build được hoàn thành

Để theo dõi build process của bạn, bạn có thể tạo các alert mà gửi e-mail messages đến cho bạn hay các người khác khi một build được hoàn thành.

Tài nguyên bổ sung

Để có thêm thông tin về build notifications, hãy xem "How to: Receive Build Notification E-Mail" tại http://msdn2.microsoft.com/en-us/library/ms181725(VS.80).aspx
Để có thêm thông tin về build notifications, hãy xem "How to: Add or Edit Alerts" tại http://msdn2.microsoft.com/en-us/library/ms181335(VS.80).aspx

Branching

• Sử dụng các Team Build Types mới khi tạo một partial branch.

• Chỉnh sửa các path để giải quyết trong TFSBuild.proj files, khi tạo một complete branch.

Sử dụng các Team Build Types mới khi tạo một partial branch

Khi bạn tạo một branch mà chứa một tập con các solution trong team project của bạn, bạn cần phải tạo mới các build type để build thành công.

Có hai loại partial branches:

Tài nguyên bổ sung

Để có thêm thông tin về làm thế nào để update các build type của bạn, hãy xem "How to: Update Build Types on Branched Team Projects" tại http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx

Chỉnh sửa các path để giải quyết trong TFSBuild.proj files, khi tạo một complete branch

Để thực thi update, check out các build type từ các branch mà bạn muốn chỉnh sửa modify, áp dụng các update, và sau đó commit các thay đổi đến các branch.

Tài nguyên bổ sung

Để có thêm thông tin về làm thế nào để update các build type, hãy xem "How to: Update Build Types on Branched Team Projects" tại http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx

Check-in Policies

• Sử dụng các check-in policies để nâng cao check-in quality.

• Sử dụng check-in policies để liên kết các work items với việc build.

Sử dụng các check-in policies để nâng cao check-in quality

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo và sử dụng một custom check-in policy, hãy xem "How To: Step Through Creating Custom Check-in Policies for TFS" trong tài liệu này.
Để tìm hiểu làm cách nào để tùy chỉnh một check-in policy, hãy xem "Walkthrough: Customizing Check-in Policies and Notes" tại http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx
Để xem các phần code đơn giản mà sẽ disallow các selected patterns trong check-in, hãy xem "Check-in Policy to Disallow Certain Patterns" tại http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx

Để tìm hiểu làm thế nào để đăng kí một check-in policy mới, hãy xem "I've Made a New Check-In Policy! How Do I Add It?" tại http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx

Sử dụng check-in policies để liên kết các work items với việc build

Thiết lập các Work Items check-in policy để buộc các lập trình viên phải liên kết các check-in của họ với một work item.

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo và sử dụng một custom check-in policy, see "How To: Step Through Creating Custom Check-in Policies for TFS" trong tài liệu này.
Để tìm hiểu làm thế nào để tùy chỉnh một check-in policy, see "Walkthrough: Customizing check-in Policies and Notes" tại

http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx

Continuous Integration Builds

• Sử dụng một CI build để lấy các feedback nhanh chóng trên các check-ins.

• Sử dụng một rolling build nếu các CI build có ảnh hưởng không tốt đến hiệu suất của build server performance.

• Đảm bảo là tần số(frequency) của các rolling build của bạn thường nhỏ hơn số build times.

Sử dụng một CI build để lấy các feedback nhanh chóng trên các check-ins

Mặc dù Visual Studio 2005 Team Foundation Server không cung cấp một CI solution out of the box, nó đã cung cấp framework cho bạn để thực thi CI build solution của bạn.

Tài nguyên bổ sung

Để có thêm các thông tin về các CI build, hãy xem "Chapter 8 - Setting Up a Continuous Integration Build with Team Build" trong tài liệu này.
Để có thêm các thông tin về cài đặt một CI build, hãy xem "How To - Set Up a Continuous Integration Build with Visual Studio Team Foundation Server" trong tài liệu này
Để có thêm các thông tin về làm thế nào để sử dụng VSTS CI solution, hãy xem "Continuous Integration Using Team Foundation Build" tại http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx
Để download the Visual Studio Team System CI solution MSI, hãy đến http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi
Để có thêm các thông tin về agile development và CI trong TFS, hãy xem "Extend Team Foundation Server to Enable Continuous Integration" tại http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx

Sử dụng một rolling build nếu các CI build có ảnh hưởng không tốt đến hiệu suất của build server performance

Chiều dài của Team Build được tính bằng phút.
Tần số trung bình của các check-in được tính bằng phút.
Time window during which frequent check-ins occur

Tài nguyên bổ sung

Để có thêm thông tin về cài đặt các CI build, hãy xem "Chapter 8 - Setting Up an Continuous Integration Build with Team Build" trong tài liệu này.

Hãy chắc là tần số của các Rolling Build của bạn nhỏ hơn số lần Build Times

Tài nguyên bổ sung

Để có thêm thông tin về các CI build, hãy xem "Chapter 8 - Setting Up a Continuous Integration Build with Team Build" trong tài liệu này.