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.

Hướng dẫn: Team Build( phần 2)

Nguyễn Thị Như Quỳnh — Mon, 14 Dec 2009 20:38:07 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/15/2009 4:38:07 AM

Customization

• Sử dụng một bước post-build tùy chỉnh để build một installer project.

• Sử dụng MS Build Toolkit Extras để build Microsoft .NET 1.1 applications.

• Sử dụng TFSBuild.proj để chỉnh sửa build của bạn.

• Sử dụng một bước pre-build tùy chỉnh để build một project có sự phụ thuộc đến team project khác.

Sử dụng một bước post-build tùy chỉnh để build một installer project

Vì Team Build mặc định không hỗ trợ các setup project, bạn nên sử dụng một bước post-build tùy chỉnh để biên dịch setup project và copy các tập tin binary đến các vị trí build drop location.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Walkthrough: Configuring Team Foundation Build to Build a Visual Studio Setup Project" tại http://msdn2.microsoft.com/en-us/library/ms404859(VS.80).aspx

Sử dụng MS Build Toolkit Extras để build Microsoft .NET 1.1 applications

Team Build mặc định không hỗ trợ các ứng dụng .NET 1.1 applications. Bộ MSBuild Extras - Toolkit dành cho .NET 1.1 (MSBee) cho phép các build trong .NET 1.1 nhưng lại đòi hỏi rằng các project của bạn và các solution phải được upgraded đến Visual Studio 2005. Nếu bạn không thể upgrade đến Visual Studio 2005 projects and solutions, bạn có thể sử dụng một custom post-build step để biên dịch các .NET 1.1 applications.

Tài nguyên bổ sung

Để download MSBee, tại đây http://www.codeplex.com/MSBee
Để có thêm thông tin về việc tạo một custom post-build step(bước post-build tùy ý bạn) để biên dịch một .NET 1.1 application, hãy xem tại Nagaraju's blog entry ở đây http://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx

Sử dụng TFSBuild.proj để chỉnh sửa build của bạn

Để chỉnh sửa thông tin về build-như là build server, drops location, hay build directory-bạn có thể chỉnh sửa file TFSBuild.proj.

File TFSBuild.proj chứa rất nhiều thông tin cần thiết dùng để thực thi một Team Build. Thông tin này gồm có các build location và những gì mà build nên thực thi phân tích code tĩnh(static code analysis) và các unit test(kiểm thử đơn vị). Để chỉnh sửa build, bạn chỉnh sửa file TFSBuild.proj.

Để chỉnh sửa TFSBuild.proj file

1. Kiểm tra các file từ source control.

2. Cập nhật các thông tin build trong các file.

3. Kiểm tra lại các file, cam kết thay đổi.

Lần tiếp theo khi mà build được thực thi, nó sẽ sử dụng build data đã sữa chữa.

Tài nguyên bổ sung

Để có thêm thông tin về tùy chỉnh Team Foundation Build, hãy xem "Customizing Team Foundation Build" tại http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx

Sử dụng một bước pre-build tùy chỉnh để build một project có sự phụ thuộc đến team project khác.

Team Build không hỗ trợ build các solution ngang qua giữa các team project. Để cho phép điều này xảy ra, bạn phải tùy chỉnh file TFSBuild.proj để kiểm tra phần code bạn cần từ các project khác mà các build của bạn phụ thuộc vào.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Working with multiple team projects in Team Build" tại http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx
Để có thêm thông tin về tùy chỉnh các Team Foundation Build, hãy xem "Customizing Team Foundation Build" tại http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx

Deployment : Triển Khai

• Trên các team lớn, install các build service trên một separate server(server riêng biệt).

Trên các Team lớn, Install các Build Services trên một Separate Server

Build( biên dịch chương trình) cho các đội( team) lớn mất rất nhiều thời gian và cần sử dụng khá lớn nguồn tài nguyên của server. Nếu bạn chạy các build của bạn trên Team TFS server, điều này ảnh hưởng đến đô tin cậy, hiệu suất, và khả năng mở rộng của server.

Để cải thiện hiệu suất build của bạn và giảm việc load trên tầng application của bạn, bạn nên chạy các build trên một server riêng biệt dùng để build.

Tài nguyên bổ sung

Để download bộ Team Foundation Installation Guide, hay có thêm nhiều thông tin về việc installing TFS and Team Build, hãy đến http://www.microsoft.com/downloads/details.aspx?FamilyId=E54BF6FF-026B-43A4-ADE4-A690388F310E&displaylang=en

Performance

• Sử dụng các incremental build để nâng cao hiệu suất.

• Tránh đồng bộ hóa các folder dự phòng trong việc build của bạn.

• Sử dụng các workspace để tránh việc kiểm tra các file và các project không mong muốn khi đang thực hiện một Team Build

• Xem xét việc sử dụng nhiều build machine để nâng cao hiệu suất.

Sử dụng các incremental build để nâng cao hiệu suất

Mặc định, Team Build dọn dẹp các thư mục mà nó sử dụng để thực hiện việc build trước khi nó kiểm tra các cây source control hoàn toàn cần thiết cho việc build. Team Build cũng xóa bỏ và khởi động lại các workspace được sử dụng để kiểm tra các source cho việc build. Để nâng cao hiệu suất, bạn có thể thiết lập cho Team Vuild chỉ lấy các source đã thay đổi kể từ lần Team Build cuối cùng

Nếu số lượng các source cần thiết cho một build lớn và build server thì xa từ TFS server, thì việc kiểm tra các source code có thể mất nhiều thời gian để thực hiện. Trong trường hợp đó, bạn nên xem xét sử dụng một incremental build. Để thực hiện incremental build, bạn cần thiết lập một vài các giá trị trong tập tin TFSBuild.proj của bạn thành giá trị true. Bạn cần làm:

Stop Team Build từ việc dọn dẹp các thư mục build cục bộ và các thư mục source.
Stop Team Build từ việc tạo lại các workspace được sử dụng cho việc build.
Cấu hình Team Build để chỉ lấy các source đã được thay đổi từ source control.

Để thực hiện một incremental build

1. Tạo mới một build type để đại diện cho incremental build.

2. Kiểm tra để chỉnh sửa tập tin TFSBuild.proj liên quan đến các incremental build type mà bạn vừa tạo.

3. Thêm phần sau <PropertyGroup> ngay trước khi phần tử </project> đóng trong TFSBuild.proj:

<PropertyGroup>

<SkipClean>true</SkipClean>

<SkipInitializeWorkspace>true</SkipInitializeWorkspace>

<ForceGet>false</ForceGet>

</ PropertyGroup>

Các cài đặt này thực hiện như sau:

SkipClean. Thiết lập cho SkipClean thành true để đảm bảo là việc build sẽ không dọn dẹp các local build và sources folder.
SkipInitializeWorkspace. Thiết lập cho SkipInitializeWorkspace thành true để đảm bảo là build sẽ ra khỏi workspace đã có trong build machine.
ForceGet. Thiết lập cho ForceGet thành false để đảm bảo là việc build sẽ chỉ nhận các source đã được cập nhật, hơn là nhận tất cả các source cho workspace.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Practices at a Glance - Team Build" trong tài liệu này.
Để có thếm thông tin về việc cấu hình một incremental build, hãy xem "How to: Configure Team Foundation Build for an Incremental Build" tại http://msdn2.microsoft.com/en-us/library/aa833876(VS.80).aspx

Tránh đồng bộ hóa các folder dự phòng trong việc build của bạn

Bạn nên giảm workspace mapping của bạn xuống hay các cloak folder mà không cần thiết như một phần của quá trình build.

Khi bạn thực thi một Team Build, server truy tìm tất cả các file mà nó cần từ source control. Tất cả file mà được truy tìm, được xác định bởi các workspace dùng để tạo các Team Build Type. Một số file được map(ánh xạ) vào trong workspace có lẽ không cần thiết. Bạn có thể thay đổi định nghĩa workspace definition của bạn để giảm các folder được bao gồm trong đó, hay bạn có thể cloak các file không cần thiết để chúng không được truy tìm như một phần của quá trình build.

Thí dụ, mặc định sự mapping cho một project mới là $/TeamProject. Nếu tất cả source file của bạn được nằm dưới $/TeamProject/foo/bar/foobar/sources, bạn nên chỉ map thư mục đó.

Để cloak các file ở bên dưới workspace mapping của bạn, bạn có thể chỉnh sửa tập tin WorkspaceMapping.xml mà được tạo khi Team Build Type được tạo và được sử dụng để xác định các folder mà được truy tìm khi đang thực hiện việc build. Bạn có thể cloak các file và các folder không cần thiết như một phần của quy trình build. Folder cloaking được ưa chuộng hơn vì việc cloak các individual file có thể giới thiệu chi phí bảo trì.

Để cloak các folder

1. Hãy kiểm tra tập tin WorkspaceMapping.xml từ source control.

2. Và thêm các mục cloak thích hợp vào file này.

3. Kiểm tra tập tin WorkspaceMapping.xml.

Thí dụ sau đảm bảo là documentation folder sẽ không được truy tìm từ source control trong suốt một Team Build:

<InternalMapping ServerItem="$/MyTeamProject"

LocalItem="c:\projects\teamproject" Type="Map" />

<InternalMapping ServerItem="$/MyTeamProject/documentation" Type="Cloak"

</Mappings>

Tài nguyên bổ sung

Để có thêm thông tin về các cloaking folder trong một workspace, hãy xem "How to: Cloak and Decloak Folders in a Workspace" tại http://msdn2.microsoft.com/en-us/library/ms181378(VS.80).aspx

Để có thêm thông tin về việc tạo Team Build loại bỏ các folder, hãy xem "How to make 'Team Build' skip getting certain folders?" tại http://blogs.msdn.com/manishagarwal/archive/2005/10/13/480584.aspx

Để có thêm thông tin về WorkspaceMapping schema, hãy xem "Schema for the WorkspaceMapping.xml file" tại http://blogs.msdn.com/buckh/archive/2007/02/28/schema-for-the-workspacemapping-xml-file.aspx

Sử dụng các workspace để tránh việc kiểm tra các file và các project không mong muốn khi đang thực hiện một Team Build

Team Build kiểm tra các source của bạn để thực thi quá trình build. Nếu bạn có một cây source tree cho một project, việc kiểm tra các source có thể rất tốn thời gian. Nếu bạn chỉ build một phần của team project, bạn nên đảm bảo là chỉ các source cần thiết được kiểm tra.

Nếu bạn có một team project lớn, nó sẽ chứa nhiều Visual Studio solutions, mỗi solution được sử dụng để build một phần riêng biệt của team project. Khi bạn tạo một Team Build Type, bạn xác định solution mà Team Build sẽ sử dụng. Nếu bạn xác định một solution file mà không xác định một workspace, Team Build sẽ kiểm tra tất cả các source ở trong team project trước khi thực hiện một quá trình build.

Để chỉ kiểm tra những source mà bạn cần, đầu tiên bạn phải xác định một workspace. Trước khi tạo Team Build Type, đầu tiên bạn xác định một workspace và chỉ map solution mà bạn muốn để build workspace đó. Khi bạn xác định Team Build Type, hãy chọn workspace mà bạn đã xác định và sau đó chọn solution. Bằng cách này, chỉ các những source đã được xác định trong workspace sẽ được kiểm tra.

Tài nguyên bổ sung

Để có thêm thông tin về việc tạo một Team Build Type, hãy xem "Walkthrough: Creating a Build Type in Team Foundation Build" tại đây http://msdn2.microsoft.com/en-us/library/ms181286(VS.80).aspx

Để có thêm thông tin về tại các Team Build kiểm tra tất cả source code trong một workspace, hãy xem "Why does Team Build sync all sources in spite of my selecting only a subset of solutions?" tại đây http://blogs.msdn.com/anutthara/archive/2005/12/07/500923.aspx

Xem xét việc sử dụng nhiều build machine để nâng cao hiệu suất

Nếu bạn có nhiều build type mà tất cả đều đang thực thi trên một single build server, thì server có thể bị tràn(overwhelmed). Trong tình huống như thế, bạn nên xem xét việc thực thi các build type khác nhau trên các build server khác nhau.

Một quá trình build có thể mất nhiều thời gian để thực thi, đặc biệt nếu build đó là dành cho một project lớn. Nếu bạn đang sử dụng CI hay các frequent scheduled build, thì build server có thể không có khả năng giữ một khối lượng build đang được khởi tạo.

Bạn có thể install nhiều build server để phân phối việc load giữa các server khác nhau. Hãy chỉ định các build type khác nhau cho từng server đến thậm chí các build load.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chương 7 - Giải thích Team Build" trong tài liệu này.

Projects

• Tránh sự phụ thuộc qua lại giữa các team project.

• Sử dụng các project reference thay vì các file reference.

• Sử dụng Web Deployment Project cho các Web application.

• Sử dụng một chiến lược single-solution strategy nếu bạn đang làm việc trên một team project nhỏ.

• Sử dụng một chiến lược 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 nhỏ độc lập nhau.

• Sử dụng một chiến lược 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 các project nhỏ độc lập.

Tránh sự phụ thuộc qua lại giữa các Team Project.

Thông thường, bạn nên tránh sự phụ thuộc qua lại giữa các team project và hãy cố gắng để giữ cho tất các các các solutions/projects có liên quan hay độc lập nhau ở bên dưới của cùng một team project. Điều này giảm sự cần thiết của việc tùy chỉnh các build script. Nếu bạn có một phụ thuộc dependency nào đó,hãy sử dụng các project references để xác định nó, hay branch các dependency từ một shared project ở trong project của bạn. Bạn nên tránh các file references bởi vì quản lý chúng rất khó khăn.

Tài nguyên bổ sung

Để có thêm thông tin về tạo một workspace, hãy xem "How to: Create a Workspace" tại http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx
Để có thêm thông tin về chỉnh sửa một workspace, hãy xem "How to: Edit a Workspace" tại http://msdn2.microsoft.com/en-us/library/ms245466(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

Sử dụng các project reference thay vì các file reference

Nếu bạn cần reference các assembly khác trong cùng một Visual Studio solution, bạn nên sử dụng một Visual Studio project reference. Bằng cách sử dụng các project reference, bạn kích hoạt Visual Studio để làm một vài việc tự động cho bạn, như là giữ sự cấu hình build bất đồng bộ (debug/release) và theo dõi các version và build lại các thành phần cần thiết khi ráp lại các versions change.

Tài nguyên bổ sung

Để có thêm thông tin về các project references, hãy xem "Project References" tại http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx

Sử dụng Web Deployment Project cho các Web application

Các web deployment project có liên kết với một Visual Studio Web Site project hay Web Application project. Chúng cho phép bạn quản lý các thiết lập build cũng như là một loạt các thiết lập phổ biến khác đến các ASP.NET Web applications. Thí dụ, deployment project (triển khai dự án) cho bạn một cách thức truy cập dễ dàng đến Web.config, connection strings, và các thư mục virtual directories, và cho phép bạn triển khai dễ dàng hơn các ứng dụng biên dịch Web đến các hosting server.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Visual Studio 2005 Web Deployment Projects" tại http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx

Sử dụng một chiến lược single-solution strategy nếu bạn đang làm việc trên một team project nhỏ.

Nếu bạn làm việc với một team nhỏ, hãy xem xét sử dụng một single Visual Studio solution để chứa tất cả các project của bạn. Cấu trúc này đơn giản hóa việc phát triển vì tất cả các phần code có sẵn khi bạn mở solution. Chiến thuật này cũng dễ dàng để thiết lập các reference, bởi vì tất cả các reference ở giữa các project trong solution của bạn. Bạn có thể vẫn còn cần sử dụng các file reference để reference đến các assembly ở bên cung cấp thứ ba, như là các thành phần được mua, mà ở bên ngoài solution của bạn.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chương 3 - Cấu trúc Projects và Solutions trong Source Control" trong tài liệu này.

Sử dụng một chiến lược 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 nhỏ độc lập nhau.

Nếu bạn làm việc trên một đội lớn, hãy xem xét sử dụng nhiều solution, mỗi cái đại diện cho một hệ thống con trong ứng dụng của bạn. Các nhà phát triển có thể sử dụng những solution này để làm việc trên các phần nhỏ hơn của hệ thống mà không có load tất cả các code giữa các project. Bạn nên thiết kế cấu trúc solution của bạn để bất kì project nào mà có các sự phụ thuộc được nhóm lại với nhau.

Điều này cho phép bạn sử dụng các project reference hơn là các file reference. Hãy xem xét việc tạo một master solution file mà chứa tất cả các project, nếu bạn muốn sử dụng file này để build toàn bộ ứng dụng.

Lưu ý: Nếu bạn đang build với Team Build (mà dựa vào MSBuild), có thể tạo các cấu trúc solution mà không bao gồm các referenced project. Miễn là toàn bộ solution được build đầu tiên, khởi tạo các binary output từ mỗi solution, MSBuild sẽ có thể làm theo các project references ở bên ngoài các bound của solution của bạn và build một cách thành công. Các solution được tạo bằng cách này sẽ không build từ Visual Studio build command, nhưng sẽ chỉ làm việc với Team Build và MSBuild.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chương 3 - Cấu trúc Projects và Solutions trong Source Control" trong tài liệu này.

Sử dụng một chiến lược 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 các project nhỏ độc lập

Nếu bạn làm việc trên một solution rất lớn yêu cầu đến hàng chục các project, bạn có thể chạy thử dựa vào khả năng mở rộng của solution. Trong tình hướng kịch bản này, hãy chia ứng dụng của bạn thành nhiều solution nhưng không tạo một master solution cho toàn bộ ứng dụng bởi vì tất cả các reference bên trong từng solution là các project reference. References đến các project ở bên ngoài mỗi solution (thí dụ, đến các librarie hay các project được cung cấp bởi bên thứ ba trong các solution khác) là các file reference. Điều này có nghĩa là có thể không có "master" solution. Thay vào đó, một script phải được sử dụng mà hiểu được thứ tự của các solution phải được build. Một trong những nhiệm vụ bảo trì liên quan đến một cấu trúc nhiều solution(multiple-solution structure) là đàm bảo rằng các lập trình viên không vô tình tạo ra các sự tham chiếu reference vòng tròn giữa các solution. Cấu trúc này đòi hỏi các build script phức tạp hơn và việc mapping của các mối quan hệ phụ thuộc rõ ràng hơn. Trong cấu trúc này, không thể build toàn bộ ứng dụng trong Visual Studio. Thay vào đó, bạn có thể sử dụng TFS Team Build hay MSBuild một cách trực tiếp.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chương 3 - Cấu trúc Projects và Solutions trong Source Control" trong tài liệu này.

Scheduled Builds

Sử dụng một scheduled build để tạo ra các regular build.

Sử dụng một scheduled build để tạo ra các regular build.

Bạn nên sử dụng một scheduled build để tạo ra các build một cách thường xuyên, theo thời gian dự đoán.

Thông thường, các build cung cấp cho các test team và các team khác cần phải đạt được độ tin cậy và nên được tạo 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 gom theo đúng thời han.

Mặc dù chức năng Team Build trong TFS không được hỗ trợ các scheduled build từ giao diện người dùng, bạn có thể sử dụng Microsoft Windows Task Scheduler để chạy TFSBuild command utility để khởi động các build tại một thời gian xác định trước.

Để tạo một scheduled build

1. Tạo một dòng lệnh TFSBuild command line như sau:

TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>

2. Đặt dòng lệnh command line trên trong một batch file.

3. Tạo một Windows Scheduled Task để chạy batch file tại khoảng thời gian bạn mong muốn.

Tài nguyên bổ sung

Để có thêm thông tin, hãy xem "Chương 9 - Cài đặt Scheduled Build với Team Build" trong tài liệu này.
Để có thêm thông tin về cài đặt các scheduled build, hãy xem "Làm thế nào - Cài đặt Scheduled Build với Visual Studio Team Foundation Server" trong tài liệu này.

Test-Driven Development

• Chạy code analysis trong từng build.

• Chạy các automated test trong từng build.

• Xem xét cài đặt các build thành fail khi các automated test bị fail.

Chạy code analysis trong từng build

Sử dụng code analysis như một phần của quá trình build để cải thiện chất lượng build quality. Bạn có thể cấu hình một bước code analysis step trong quy trình build để giúp đảm bảo là code của bạn đáp ứng được các tiêu chuẩn chất lượng, bảo đảm về security, hiệu suất, tính tiện dụng, bảo trì, và các quy định về độ tin cậy được thông qua.

Để bật chế độ code analysis cho một build type, bạn có thể chọn cả code analysis check box ở trong Team Build Type wizard khi bạn tạo mới Team Build Type, hay bạn có thể chỉnh sửa tập tin TFSBuild.proj ngay sau khi build type được tạo.

Để kích hoạt code analysis trong TFSBuild.proj file

Nếu bạn muốn tất cả các project đều chạy code analysis, bất kể các thiết lập của project , hãy thay đổi tag <RunCodeAnalysis> thành Always.
Nếu bạn muốn chạy code analysis trên từng project dựa trên các thiết lập của project, hãy thay đổi tag <RunCodeAnalysis> thành Default.

Tài nguyên bổ sung

Để có thêm thông tin về automatic code analysis như một phần của một build, hãy xem "Làm thế nào - Chạy tự động Code Analysis với Team Build in Visual Studio Team Foundation Server" trong tài liệu này.
Để có thêm thông tin về các công cụ code analysis tools, hãy xem "Guidelines for Using Code Analysis Tools" tại http://msdn2.microsoft.com/en-us/library/ms182023(VS.80).aspx

Chạy các automated test trong từng build

Chạy các automated tests để tự động có được các feedback về chất lượng build sau mỗi lần build. Để tạo một danh sách các kiểm thử (test list) để liên kết với các build mà bạn phải có trong cả Visual Studio Test Edition hay Visual Studio Team Suite đã cài đặt. Để chạy các automated test trên build server bạn phải có cả Visual Studio Developer Edition, Visual Studio Test Edition, hay Visual Studio Team Suite được cài đặt trên build server.

Để chạy các automated test như một phần của quy trình Team Build process

1. Tạo một hay nhiều các automated test mà bạn muốn chạy với các build.

2. Sử dụng Test Manager để tạo một Test List.

3. Sử dụng Test Manager để nhóm các test vào trong Test List mới bằng các drag và drop các test từ Test View vào Test List ở trong Test Manager.

4. Tạo mới một Team Build Type.

5. Chọn check box để chạy automated tests.

6. Chọn test project mà với các test và test list của bạn được chọn.

7. Chọn test list mà bạn muốn chạy.

Tài nguyên bổ sung

Để có thêm thông tin về tự động chạy các build verification test, hãy xem "How to: Configure and Run Build Verification Tests (BVTs)" tại http://msdn2.microsoft.com/en-us/library/ms182465(VS.80).aspx
Để có thêm thông tin về làm cách nào để chạy các automated build tests mà không có Visual Studio Test Edition hay một VSMDI file, hãy xem"How to run tests in a build without test metadata files and test lists (.vsmdi files)" tại http://blogs.msdn.com/buckh/archive/2006/11/04/how-to-run-tests-without-test-metadata-files-and-test-lists-vsmdi-files.aspx

Xem Xét Cài Đặt Các Build Thành Fail Khi Các Automated Test Fail

Khi một build(biên dịch chương trình) thất bại bởi vì các lỗi biên dịch, một work item được tạo để theo dõi các failure và việc build được đánh dấu là thất bại. Khi một automated test thất bại, tuy nhiên, build không thất bại. Các test failure được chuyển thành một warning và quá trình build được tiếp tục.

Để một build thất bại khi kiểm thử sự thất bại(test failure)

1. Mở tập tin Microsoft.TeamFoundation.Build.targets từ Program\Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild.

2. Lấy ra để chỉnh sửa và mở tập tin TFSBuild.proj cho Team Build Type mà bạn muốn không thành công khi kiểm thử thất bại(test failure).

3. Copy target RunTestWithConfiguration target từ Microsoft.TeamFoundation.Build.targets đến phần cuối của tập tin TFSBuild.proj, ngay trước thẻ đóng của tag </Project>.

4. Chỉnh sửa thuộc tính ContinueOnError từ true sang false.

Lưu ý: Sẽ có hai test tool task. Chỉnh sửa các end-to-end task chỉ để thay đổi trạng thái của các build ở trên build server. Các desktop build task được sử dụng khi đang build trên một desktop của một lập trình viên.

5. Nếu bạn muốn tạo một work item khi build thất bại, hãy chỉnh sửa RunTestWithConfiguration bằng cách thêm một phần tử OnError ngay trước thể đóng của tag </Target> Phần tử OnError nên giống như sau:

<OnError ExecuteTargets="CreateWorkItem;"/>

Bạn có lẽ muốn build thất bại nếu một automated test liên kết bị thất bại. Bạn có lẽ cũng muốn khởi tạo một work item một cách tự động để theo dõi các test failure.

Ngoài ra, nếu bạn muốn tất cả các Team Build Types bị thất bại khi kiểm thử sự thất bại test failure, bạn có thể chỉnh sửa target Microsoft.TeamFoundation.Build.targets một cách trực tiếp. Sự thay đổi này sẽ thay đổi tình trạng của tất cả các Team Build Types.

Các giải pháp được đề nghị ở trên thực hiện đơn giản nhưng không bảo đảm được tiếp tục có thể làm việc trong các phiên bản trong tương lai của Visual Studio. Nếu bạn thích thực hiện một giải pháp chắc chắn có thể làm việc tiếp tục với các phiên bản VS sau khi upgrade, hãy xem Aaron Hallberg's blog entry, "Determining Whether Tests Passed in Team Build," tại http://blogs.msdn.com/aaronhallberg/archive/2006/09/21/determining-whether-tests-passed-in-team-build.aspx

Tài nguyên bổ sung

Để có thêm thông tin về thiết lập một build để tạo một work item khi kiểm thử test failure, hãy xem "Create Workitems for Test Failures in TeamBuild" tại http://blogs.msdn.com/nagarajp/archive/2005/10/14/481290.aspx
Để có thêm thông tin về một giải pháp đảm bảo có thể làm việc iếp tục sau khi Visual Studio upgrade, hãy xem "Determining Whether Tests Passed in Team Build" tại http://blogs.msdn.com/aaronhallberg/archive/2006/09/21/determining-whether-tests-passed-in-team-build.aspx

Work Items

Sử dụng các work item để theo dõi các build break.

Sử Dụng Các Work Item Để Theo Dõi Các Build Break

Nếu Team Build thất bại, nó sẽ tự động tạo một work item để theo dõi failure đó. Mặc định, phần work item đó sẽ được chỉ định thành 'Active' và title sẽ thông báo cho bạn là có một build failure. Bạn nên chỉ định cho work item này để lập trình viên chịu trách nhiệm hay nhà quản lý việc build để sữa chữa build và giải quyết problem.

The build task trong TFSBuild.proj mà xác định work item này giống như sau:

<CreateNewWorkItem

BuildId="$(BuildNumber)" Description="$(WorkItemDescription)"

TeamProject="$(TeamProject)"

TeamFoundationServerUrl="$(TeamFoundationServerUrl)"

Title="$(WorkItemTitle)"

WorkItemFieldValues="$(WorkItemFieldValues)"

WorkItemType="$(WorkItemType)"

ContinueOnError="true" />

Nếu bạn muốn tùy chỉnh work item được tạo (thí dụ, để chỉ định cho nó một lập trình viên cụ thể hay để đặt tính nghiêm trọng và độ ưu tiên), bạn có thể thay đổi trường WorkItemFieldValues field.

Tài nguyên bổ sung

Để có thêm thông tin về tùy chỉnh build failure work item, hãy xem "Team Foundation Build Tasks" tại http://msdn2.microsoft.com/en-us/library/ms243778(vs.80).aspx

Build Resources

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

Chương 18 – Có gì mới trong Visual Studio 2008 Team Foundation Server

Nguyễn Thị Như Quỳnh — Mon, 14 Dec 2009 20:26:32 GMT

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

Microsoft® Visual Studio® 2008 Team Foundation Server giới thiệu một số các chức năng và khả năng mới. Những thay đổi chính:

Administration, Operations & Setup. Việc cài đặt được đơn giản hóa để giảm thời gian cài đặt và cải thiện để hỗ trợ nhiều kịch bản triển khai hơn.
Build. Các build gồm có Continuous Integration, scheduled builds, and build queuing solutions out of the box. Quản lý và mở rộng các Build đã được đơn giản hóa với nhiều tính năng có sẵn từ các UI.
Version Control. Version control gồm có các hỗ trợ tốt hơn cho công việc offline và đã được nâng cao cải thiện hiệu suất.
Work Item Tracking. Work item tracking gồm có một query builder được cải thiện và nâng cao hỗ trợ cho các work item attachments.

Những sự thay đổi của các sản phẩm này được liệt kê và mô tả ngắn gọn dưới đây, tiếp theo là một bảng giải thích về những sự thay đổi này sẽ ảnh hưởng đến sự hướng dẫn trong tài liệu này như thế nào. Sử dụng chương này để trợ giúp cho Microsoft Visual Studio Team Foundation Server của bạn lên kế hoạch nâng cấp.

Administration, Operations & Setup

Simplified installation -Việc cài đặt được thực hiện dễ dàng hơn và nhanh hơn so với Visual Studio 2005 TFS. Những việc cải tiến bao gồm loại bỏ sự cài đặt tầng data riêng biệt cũng như loại bỏ các yêu cầu của domain account. Team Foundation Server 2008 hỗ trợ built trong các machine accounts (như là Network Service) bất cứ khi nào có thể.
Support for SharePoint 2007 -Thêm các support cho SharePoint 2007 và Windows SharePoint Services 3.0. Team Foundation Server 2008 sẽ support SharePoint trên một separate server from từ Team Foundation Application Tier Server.
Support for Windows Server 2008 - Hỗ trợ các phiên bản tiếp theo của Microsoft Windows Server^TM; thí dụ Microsoft Windows Server 2008 và Internet Information Services (IIS) 7.0.
Support for X.509 Client Certificates - Hỗ trợ sử dụng của X.509 client certificates để nâng cao sự cải thiện bảo mật.
Large group synchronization - Cải thiện hiệu suất và độ bền và sẽ có thể support một số lượng lớn các user - khoảng 30,000 user hay nhiều hơn trong một single instance of TFS.
Support for SQL named instances -Cho phép sự chia sẻ SQL Server giữa các multiple TFS instances, hay với các ứng dụng khác. Điều này cho phép các instance khác nhau của TFS sử dụng sự cài đặt SQL Server 2005 giống nhau.
Support for non-default ports - Tăng cường khả năng hiệu chỉnh để hỗ trợ các trang Web phụ và các cổng phụ.

Build

Continuous Integration builds -Hỗ trợ sự khởi tạo của các build trigger mà cho phép bạn cấu hình một cách chính xác khi các Continuous Integration builds được khởi động. Thí dụ, bạn có thể set một trigger để tất cả check-in bắt đầu một build, hay bạn có thể thiết lập một rolling build để các build sẽ bắt đầu không thường xuyên hơn với mỗi X phút.
Support for build queuing -Hỗ trợ build queuing và quản lý hàng đợi. Điều này thật hữu ích cho Continuous Integration như là các multiple check-ins có thể xếp hàng đợi cho các multiple build.
Scheduled builds -Hỗ trợ các scheduled build, mà có thể được cấu hình để bắt đầu tại những thời gian cụ thể dựa trên các yêu cầu của tổ chức của bạn.
Drop management -Hỗ trợ các drop management, cho bạn các khả năng để thiết lập các chính sách policy khi các build nên được xóa một cách tự động.
Specify build properties - Cho phép bạn xác định source và các version nào của source nên được build cùng với các thuộc tính của build khác cho một build type. Có nhiều thuộc tính được trình bày cho việc tùy chỉnh một build. Ngoài ra, các tham số MSBuild command-line có thể được thông qua khi queue các build.
Extensibility of build targets -Cải tiến mở rộng các build target. Thí dụ, bây giờ bạn có khả năng thực thi một cách dễ dàng các target trước và sau mỗi Visual Studio solution hay project được build.
Build management -Cho phép bạn stop hay delete các build từ Visual Studio.
Build configuration -Đơn giản hóa khả năng xác định test nào được hạy như là một phần của một build.
Build project file location flexibility -Cung cấp khả năng lưu trữ MSBuild project file (và các rsp file kết hợp của nó) bất cứ nơi nào trong các version control hierarchy thay vì bắt buộc phải sử dụng TeamBuildTypes folder.
Support for GUI tests - Cho phép chạy các kiểm thử giao diện đồ họa người dùng(graphical user interface (GUI) test) như là một phần của các build.
Check-in Policy - Hỗ trợ một check-in policy mới, giúp chặn các user từ các check-in code khi một Continuous Integration build bị break.
Managing build server - Cải thiện khả năng để quản lý các multiple build machines.
Workspace mapping - Build definition có thể được kết hợp với một "real" workspace, meaning code từ các multiple team project có thể được tìm kiếm, các client mapping có thể được xác định, vv.... Working folder mappings sẽ được quản lý trong GUI thay vì trong workspacemapping.xml

Version Control

Annotate -Hỗ trợ một tính năng chú thích mà cho phép các nhà lập trình của bạn kiểm soát một file source code và thấy được chi tiết mức độ từng dòng về ai là người cuối cùng thay đổi từng phần code.
Folder Diff -Hỗ trợ so sánh các folder nơi mà nội dung của các folder được so sánh một cách đệ quy để xác định các file khác nhau. Folder Diff có thể so sánh các local folder với các local folders, local folders với server folders, và server folders với server folders.
Destroy -Hỗ trợ chức năng Destroy(Hủy bỏ) với khả năng remove các file và các folder từ các version control system. Các files và folders không thể phục hồi sau khi bị hủy bỏ.
Get Latest On Checkout -Gồm có một tùy chọn cho download phiên bản mới nhất của file trong khi đang thanh toán.
Workspace wild card mappings -Cho phép sự ánh xạ(mapping) của một folder hay file dưới một folder đã được cloak và ánh xạ wildcard(wildcard mapping) để bạn có thể map tất cả các file trong một folder mà không map các folder con.
Performance improvements - Một loạt các phiên bản cải tiến kiểm soát hiệu suất(version control performance enhancement) được thực hiện, cải thiện tất cả các khía cạnh của phiên bãn kiểm soát hiệu suất(version-control performance). Mặc dù tất cả những lợi nhuận của các servers/projects nhỏ hơn (< 10,000 files) sẽ khiêm tốn, lợi ích cho các project lớn hơn (đặc biệt là nơi có các file số phương pháp là hàng trăm ngàn) sẽ rất đáng kể.
Team Foundation Server 2008 command line Help -Hỗ trợ khả năng để có được command line Help cho tf tool. Bạn lấy dòng lệnh Help bằng cách chạy "tf help" và chứa các Help cho các command riêng lẻ bằng cách chạy "tf command /help".
Offline improvements - Cải thiện kinh nghiệm offline và đã được tích hợp khả năng tfpt online vào Visual Studio Integrated Development Environment (IDE) cho việc trở lại online.
Check-in override information captured -Hỗ trợ việc thêm các check-in policy đè lên các warehouse.

Work Item Tracking

Attachments improvements - Hỗ trợ drag-and-drop support cho việc thêm một attachment và cho phép multi-select cho các attaching file.
Query Builder -Khả năng Query Builder đã được cải thiện trong các cách sau:

o Drop-down filtering bây giờ dựa trên project hiện có.

o Cải tiến danh sách MRU lists

o Column drag-and-drop

o SHIFT + click mouse dựa trên multi-column sorting

Các vấn đề tương thích với Visual Studio 2005 Team System

The Visual Studio 2008 Team Foundation Server client có thể làm việc với một Visual Studio 2005 Team Foundation Server và một Visual Studio 2005 client có thể làm việc với một Visual Studio 2008 Team Foundation Server, ngoại trừ các vấn đề về tương thích sau đây:

Visual Studio add-ins - Client-side Visual Studio add-ins sẽ cần để được recompiled (hay các policy của chúng bị thay đổi) bởi vì các Team Foundation Server Object Model (TFSOM) assembly version sẽ thay đổi và các add-in sẽ cần để bind đến các assembly mới.
Team builds - Hầu hết các hoạt động build - như là lên danh sách các build definition, starting và stopping builds và các examining build reports sẽ làm việc với sự kết hợp của Visual Studio 2005 TFS và Visual Studio 2008 clients và server. Sau đây là các vấn đề được biết:

1. Một Visual Studio 2008 Team Foundation Server instance sẽ chỉ làm việc với một Visual Studio 2008 Team Foundation Server build server.

2. Đối với một Visual Studio 2005 client để bắt đầu một build trên một Visual Studio 2008 Team Foundation Server instance, the build definition cần được lưu trữ tại $/<TeamProject>/TeamBuildTypes/<name>.

3. Thay đổi thực hiện các property trong tfsbuild.proj file ở trong database trong Team Foundation Server 2008 sẽ không được update trong database và sẽ không còn được đồng bộ.

4. Khi làm việc với chức năng Continuous Integration feature trong Team Foundation Server 2008, the Visual Studio 2005 client sẽ có thể bất đầu một build, nhưng nó sẽ không thể queue một build, hãy xem danh sách các build trong hàng đợi(queue), hãy xem danh sách của các build agents, vv....

5. Một loại build mới không thể được tạo trên một Visual Studio 2005 TFS server, sử dụng một Visual Studio 2008 Team Foundation Server client.

6. Các tham số trong dialog cho việc bắt đầu một build trên Visual Studio 2005 Team Foundation Server không thể được thay đổi khi sử dụng một Visual Studio 2008 Team Foundation Server client.

Ảnh hưởng đến tài liệu hướng dẫn

Guidance for Visual Studio 2005 Team Foundation Server	Guidance for Visual Studio 2008 Team Foundation Server
Dual server deployment sẽ support lên đến 2000 user.	Bạn có thể sử dụng dual server deployment để support lên đến 30,000 user.
User cần các domain account đúng như là một phần của sự triển khai deployment.	Domain accounts không còn bị đòi hỏi, thay vào đó bạn có thể sử dụng build trong machine accounts, như là Network Service account.
Sử dụng một custom solution để tạo các Continuous Integration builds.	Bạn có thể sử dụng các Visual Studio build trigger để tạo và cấu hình các Continuous Integration builds hay Rolling builds.
Sử dụng các automated test như là một phần của build của bạn để đo lường chất lượng của các build.	Dễ dàng hơn để build test lists và xác định test nào được run như một phần của một build step. Có thể để run các GUI test như một phần của automated build tests.
Build types phải được đặt trong một folder cụ thể để Team Build có thể nhận ra chúng.	Build definition project files (tfsbuild.proj) Có thể được lưu trữ bất cứ nơi nào trong version control hierarchy
Sử dụng một custom solution để tạo các Scheduled Builds.	You can create Visual Studio scheduled builds without the need for a custom solution.
Có một tập các check-in policy có sẵn trong out-of-box.	Một check-in policy mới có sẵn cho các broken CI builds. Điều này ngăn các check-in of code trong khi các CI build bị break.
Sử dụng tool converter.exe để di chuyển từ VSS đến Team Foundation Server.	Sử dụng Visual Studio toolkit cho building conversion và mirroring solution giữa Team Foundation Server và các source control systems khác - gồm cả VSS.
Sử dụng workspace mapping để xác định tập các file bạn muốn đồng bộ cho local machine.	Team Foundation Server 2008 hiện cho phép mapping của một folder hay file bên dưới một cloaked folder, và wildcard mappings để bạn có thể map tất cả các file trong một folder mà không có mapping các folder con.
Sử dụng workspacemapping.xml file để chỉnh sửa các workspace mapping.	The Team Foundation Server 2008 GUI được sử dụng để quản lý workspace mapping, workspacemapping.xml không còn được sử dụng.
Sử dụng TFS Power Tool để làm việc offline.	Sử dụng Visual Studio IDE cho làm việc offline.
Nhận phiên bản mới nhất của một file và kiểm tra nó để chỉnh sửa hai sự hoạt động source control riêng biệt.	Bạn có thể sử dụng một tùy chọn, để nhận tự động phiên bản mới nhất của một file khi bạn kiểm tra nó để chỉnh sửa.
Tùy chỉnh các bước trước khi build để lấy các phụ thuộc(dependency) khi reference đến project assembly từ một team project khác.	The build definition workspace template được quản lý trong VS GUI và có đầy đủ tính linh hoạt của một workspace tiêu chuẩn,gồm có các mapping paths từ các multiple team projects
Sử dụng TFSBuild command line tool để delete các build.	Sử dụng Visual Studio IDE để stop và delete các build.

Tài nguyên bổ sung

Để có thêm thông tin trên Visual Studio 2008 Team Foundation Server hãy xem, "An Overview of Microsoft Visual Studio Code Name "Orcas" White Paper" tại http://go.microsoft.com/?linkid=6625887

Chương 17 - Truy cập đến Team Foundation Server bằng Internet

Nguyễn Thị Như Quỳnh — Mon, 14 Dec 2009 20:22:09 GMT

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

Chủ đề

Tìm hiểu các kịch bản remote access(truy cập từ xa) chính và khi nào áp dụng chúng.
Cung cấp remote access cho Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) của bạn qua Internet.
Cải thiện việc thực hiện truy cập từ xa bằng cách sử dụng Team Foundation Server Proxy.

Xem trước

Chương này giải thích làm thế nào để cung cấp truy cập từ xa(remote access) đến TFS qua Internet. Bạn có thể chọn từ một trong ba tùy chọn sau để cung cấp remote access:

Bạn có thể cung cấp truy cập đến TFS qua một virtual private network (VPN).
Bạn có thể cung cấp việc truy cập đến TFS thông qua một reverse proxy như là Microsoft Internet Security và Acceleration (ISA) Server.
Bạn có thể đặt TFS server trên một extranet.

Các phiên bản của TFS trước Service Pack 1 (SP1) chỉ hỗ trợ truy cập VPN. TFS SP1 thêm hỗ trợ cho Basic authentication. Điều này cho phép các giải pháp extranet và reverse proxy cũng như VPN.

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

Sử dụng chương này để thiết lập TFS server của bạn cho việc remote access qua Internet. Để đạt được những lợi ích tốt nhất từ chương này, bạn nên:

Sử dụng danh sách các kịch bản(scenarios list). Tham khảo danh sách các kịch bản để xác định một cách nhanh chóng phương pháp nào bạn nên áp dụng để cung cấp việc truy cập ở bên ngoài Internet đến server của bạn.
Sử dụng các walkthrough tham khảo. Sử dụng các walkthrough trong chương này qua việc hướng dẫn từng bước về cài đặt và cấu hình các certificates và Secure Sockets Layer (SSL) access được sử dụng với Basic và Digest authentication.
Sử dụng phần "Improving Remote Access Performance(Nâng cao hiệu suất truy cập từ xa)" . Đọc phần "Improving Remote Access Performance" để xác định phương pháp để giảm số lượng lưu lượng truy cập mà cần phải được gửi qua Internet.

Các chiến thuật chính

Sau đây là các giải pháp chiến lược cho việc cung cấp truy cập từ xa(remote access) đến một TFS server:

Sử dụng một kết nối VPN connection. TFS của bạn nằm bên trong internal network(mạng nội bộ), và các user ở bên ngoài truy cập vào nó qua một VPN. Những user ở bên trong truy cập TFS một cách trực tiếp.
Publish TFS của bạn thông qua một reverse proxy. TFS của bạn nằm bên trong internal network(mạng nội bộ), và một hay nhiều reverse proxy machines, như là ISA Server, đem lại các client request từ Internet đến TFS của bạn.
Locate your TFS in the extranet ("hosted scenario"). Chỉ các external clients truy cập vào TFS của bạn, và nó được đặt bên ngoài tường lửa trên một extranet.

Các kịch bản thông thường

Remote office. Nếu bạn đang hỗ trợ remote users với truy cập VPN, sử dụng giải pháp VPN. Đây là giải pháp dễ nhất để khuyến khích, cung cấp sự bảo mật dễ thực hiện, cho phép truy cập từ xa(remote access) đến tất cả các chức năng của TFS, và cho phép bạn sử dụng TFS Proxy để nâng cao khả năng thực thi.
Offshore team. Nếu bạn đang hỗ trợ remote users mà không có truy cập VPN hoặc không truy cập đến domain, hãy sử dụng các kịch bản reverse proxy scenario. Giải pháp này khó khăn hơn để cài đặt, nhưng nó cho phép các remote users truy cập vào một vị trí bên trong TFS mà không cần đến VPN.
Hosted community. Nếu bạn đang hỗ trợ một tập hợp có nhiều remote user mà đang được sử dụng một TFS cài đặt dành riêng cho họ sử dụng, như là một community development site(trang phát triển giao tiếp), sử dụng các kịch bản extranet. Giải pháp này đem lại cho bạn sự phân chia tốt nhất giữa các remote users và các internal network resources của bạn.

Sử dụng một VPN connection

Hình 17.1 trình bày kiến trúc của exposing TFS qua một VPN.

Với phương pháp này, nhóm phát triển từ xa của bạn(remote development team) sử dụng kết nối trực tiếp đến một VPN connection cho TFS của bạn trên mạng nội bộ(internal network). Nếu bạn có TFS mà không có SP1, hoặc nếu bạn yêu cầu Integrated Windows authentication, sau đó sử dụng một VPN connection chỉ là tùy chọn của bạn. TFS được thiết kế để làm việc trên các tình huống có bandwidth thấp, như là truy cập VPN , và cung cấp hiệu suất chấp nhận được khi sử dụng kịch bản này.

Lợi ích

Tất cả các chức năng làm việc của TFS , gồm có TFS Proxy.
Phương pháp này hỗ trợ việc sử dụng Integrated Windows authentication và cho phép bạn tận dụng cơ sở hạ tầng hiện có.
Nếu bạn đã cài đặt một VPN, đây là giải pháp dễ nhất để chấp nhận.

Bất lợi

Một giải pháp VPN solution có thể không được thiết lập cho các cơ sở hạ tầng của bạn, hoặc có thể không có sẵn cho các remote user của bạn.

Để có thêm thông tin về việc khởi tạo một VPN, hãy xem http://support.microsoft.com/kb/324747

Publishing TFS thông qua một Reverse Proxy

Với phương pháp này, bạn install một TFS server trên mạng nội bộ(internal network) của bạn và sử dụng chức năng ISA Server Web publishing để biểu diễn nó tới external network. Các remote user truy cập TFS qua SSL và sử dụng Basic authentication. Tùy chọn này sẽ không làm việc nếu bạn không cài đặt TFS SP1.

Networks mà không có một domain controller trên perimeter

Hình 17.2 trình bày kiến trúc biểu diễn TFS qua ISA với một domain controller trên internal network.

Nếu bạn không có một domain controller trên perimeter network của bạn, bạn có thể mở một port trên firewall để cho phép một Lightweight Directory Access Protocol (LDAP) connection từ ISA Server đến internal domain controller của bạn, đặc biệt là đến các người sử dụng xác thực ở bên ngoài TFS(authenticate external TFS users).

Networks có một domain controller trên perimeter

Hình 17.3 trình bày kiến trúc biểu diễn TFS qua ISA với một domain controller trong perimeter network.

Nếu bạn có một domain controller trên perimeter network(mạng ngoại vi) của bạn, các remote users có thể xác nhận là đúng một cách trực tiếp dựa vào perimeter domain controller. Một cách tin cậy giữa internal và perimeter domain controllers là cho phép các external user truy cập đến TFS server. Các internal user truy cập đến the TFS server một cách trực tiếp, sử dụng Integrated Windows authentication.

Ưu điểm

Reverse proxies, như là ISA Server, xác minh các user và kiểm tra lưu lượng truy cập.
Các remote user của bạn không cần truy cập đến domain.
Các remote user của bạn không cần truy cập đến VPN.

Nhược điểm

Bạn không thể sử dụng TFS Proxy tại các địa điểm từ xa
Các remote user của bạn không thêm các user vào các TFS group.
Các remote user của bạn không thêm các Microsoft Active Directory® group vào các folder trong source control.
Các remote user của bạn sẽ không thể khởi động hay quản lý các build từ xa.
Các remote user của bạn không thể tạo mới các team project.
Các remote user của bạn không thể công khai các kết quả kiểm thử với TFS của bạn.

Note: Bất cứ khi nào bạn sử dụng Basic authentication, hãy sử dụng SSL. Basic authentication transmits credentials trong clear text. Hảy sử dụng SSL để bảo vệ thông tin này.

Đặt TFS trong một Extranet ("Hosted Scenario")

Hình 17.4 trình bày kiến trúc của việc đặt TFS trong một extranet.

Với phương pháp này, bạn install toàn bộ cơ sở hạ tầng của TFS -cả tầng application và tầng data -bên trong perimeter network của bạn, off của internal intranet của bạn. Tất cả các kết nối đến TFS của bạn thông qua Internet, dù là từ các người dùng bên ngoài hay bên trong. TFS có thể làm việc với một domain controller (DC) hoặc không có DC. Nếu perimeter network của bạn không truy cập đến một DC, các chức năng của Active Directory service features của TFS sẽ không làm việc. Thí dụ, việc thêm các user đến các TFS group, hay thêm một Active Directory group đến các folder trong source control, sẽ không làm việc nếu không có một DC. Tùy chọn này sẽ không làm việc nếu bạn không cài đặt TFS SP1.

Ưu điểm

Các TFS user của bạn được phân chia rõ ràng từ internal network của bạn.
Các remote user của bạn không cần truy cập đến domain.

Nhược điểm

Bạn không thể sử dụng TFS Proxy từ các vị trí từ xa.
Các remote user của bạn không thể khởi động hay quản lý các build.
Các remote user của bạn không thể tạo mới các team project.
Các remote user của bạn không thể công khai các kết quả kiểm thử đến TFS.
Các internal user phải kết nối đến extranet TFS thông qua SSL giống như các external user.

Basic Authentication / SSL

Nếu bạn đang sử dụng TFS SP1 và muốn support các extranet hay reverse proxy scenario, bạn cần cho phép Basic authentication over SSL by configuring IIS trên tầng TFS application của bạn. Với Basic authentication, logon credentials được truyền qua Internet sử dụng một unprotected Base64 encoded format. Để bảo vệ các client's credentials, chỉ cần sử dụng Basic authentication qua một Secure HTTP (HTTPS) connection có sử dụng SSL.

Sử dụng một Internet Server API (ISAPI) filter để các remote client kết nối bằng cách sử dụng Basic authentication over SSL, trong khi các local client vẫn kết nối bằng cách sử dụng Integrated Windows authentication. The ISAPI filter tìm kiếm các client mà bạn đã cấu hình như là "external/Internet" và các strips out NTLM authentication trên 401 response để buộc các client này sử dụng các phương pháp xác thực khác, như là Basic authentication.

Thông tin bổ sung

Để có thêm thông tin về làm cách nào để cấu hình TFS server của bạn để yêu cầu Basic authentication và HTTPS qua các kết nối từ xa(remote connection), hãy xem "Walkthrough: Setting up Team Foundation Server to Require HTTPS and Secure Sockets Layer (SSL)" tại http://msdn2.microsoft.com/en-us/library/aa833873(VS.80).aspx
Để có thêm thông tin về cài đặt ISAPI filter, hãy xem "Walkthrough: Setting up Team Foundation Server with Secure Sockets Layer (SSL) and an ISAPI Filter" tại http://msdn2.microsoft.com/en-us/library/aa833872(VS.80).aspx
Để có thêm thông tin về ISAPI filters for TFS, hãy xem James Manning's blog post "The TFS extranet ISAPI filter mechanics" tại http://blogs.msdn.com/jmanning/archive/2006/10/27/the-tfs-quot-extranet-quot-isapi-filter-mechanics.aspx

Team Foundation Server Proxy

Hình 17.5 trình bày kiến trúc của việc sử dụng Team Foundation Server Proxy.

The TFS Proxy không yêu cầu cho phép kết nối từ xa(remote access) nhưng là một optional cache cho các source control files. Để giúp cải thiện năng suất từ các remote team experiences của bạn, bạn có thể install một TFS Proxy trong các remote offices mà kết nối đến TFS của bạn thông qua một VPN. Điều này nâng cao năng suất bằng việc lưu trữ các source control files trên remote office's proxy server. Bất cứ khi nào các remote client cần truy cập đến source code trong source control repository, nó sẽ yêu cầu source từ TFS Proxy. The proxy sau đó sẽ trả về một local version từ cache của nó nếu nó có sẵn. Nếu source không có trong cache, the proxy sẽ yêu cầu source từ remote TFS server. Điều này giảm thiểu network traffic và cải thiện source control responsiveness tại các vị trí từ xa(remote location).

Mẹo để nâng cao năng suất proxy

Hãy xem xét các lời khuyên sau cho việc cải thiện hiệu suất proxy:

Hãy đảm bảo là bộ nhớ đệm được kích hoạt, và giám sát hiệu suất của bộ nhớ đệm của bạn. Giám sát các performance counters (installed mặc định) và các event logs (cho các error và warnings) trên proxy server thông thường của bạn, để xem proxy của bạn được thực hiện như thế nào. Lưu ý là các TFS Proxy thống kê hiệu suất tiết kiệm bộ nhớ cache đến một tập tin Extensible Markup Language (XML) có tên là ProxyStatistics.xml, và bạn có thể thay đổi khoảng tiết kiệm của các thống kê này. File ProxyStatistics.xml được đặt trong App_Data folder trong thư mục cài đặt proxy.
Chạy một scheduled task thông thường để nhận các file mới nhất cho proxy server. Điều này giúp đảm bảo là các version mới nhất của các file có sẵn trong proxy cache, và các yêu cầu của các client tiếp theo cho các kết quả của các file này trong một cache hit.
Nếu bạn biết là các file lớn đang được download qua một mạng có bandwidth thấp (< 3 megabits per second [Mbps]), hãy gán cấu hình executionTimeout có một giá trị thích hợp trong Web.config. Giá trị mặc định trong một giờ <httpRuntime executionTimeout="3600"/>.
Nếu proxy sắp bị down trong một thời gian dài, hãy disable proxy trên các client để ngăn chặn reconnections không hiệu quả. Mặc định, các reconnection được lặp lại cứ 5 phút.
Hãy xem xét việc sử dụng workspace cloaking để ẩn các specific workspaces từ view và ngăn chặn truyền các tập tin không cần thiết. Cloaking ẩn các folder specified workspace từ from view, tăng hiệu suất băng thông(performance bandwidth), và duy trì không gian đĩa cục bộ(local disk space) bằng cách chặn copy các folder và các file mà bạn hiện không cần từ các local workspace của bạn. Mặc dù bạn có thể cloak một folder mapping đã có trong workspace của bạn, một phương pháp tốt hơn là tạo mới một folder mapping là dự định cụ thể để được cloak.

Để có thêm thông tin về các hướng dẫn tối ưu hóa hiệu suất, hãy xem "Distributed / Remote Development" tại "Hướng dẫn: Source Control Hướng dẫn" trong tài liệu này.

Mirrored Accounts

The TFS Proxy được hỗ trợ trong các remote offices chỉ qua một VPN connection. Tuy nhiên, nếu bạn triển khai TFS của bạn sử dụng extranet hay reverse proxy scenario cho một remote team nhỏ mà yêu cầu TFS Proxy, bạn có thể sử dụng các mirrored account để kích hoạt proxy.

Để kích hoạt proxy, bạn có thể sử dụng các workgroup accounts với các username và password phù hợp trên TFS, TFS Proxy, và từng remote client computers. Thực tế bạn cần duy trì chính xác username/password phù hợp cho tất cả các user trong ba vị trí khác nhau tăng quản lý về thời gian và hạn chế giải pháp thay thế này đến các remote team nhỏ.

Thông tin bổ sung

Để nghiên cứu thêm về TFS Proxy, hãy xem "Team Foundation Server Proxy and Source Control" tại http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx
Để có thêm thông tin về quản lý TFS Proxy, hãy xem "Managing Remote Connections to TFS Proxy" tại http://msdn2.microsoft.com/en-us/library/ms253156(VS.80).aspx
Để có thêm thông tin về troubleshooting the TFS Proxy, hãy xem "Troubleshooting TFS Server Proxy" tại http://msdn2.microsoft.com/en-us/library/ms400681(VS.80).aspx

Build Server từ xa

Hình 17.6 trình bày kiến trúc của việc sử dụng một remote build server.

Để cải thiện năng suất của các remote teamhơn nữa, bạn có thể cài đặt một build server trong remote office. Nếu bạn có cài đặt một TFS Proxy trong remote office, nó sẽ hoạt động giống như bất kì source control client nào khác và nhận code từ các proxy trước mỗi build. Một remote build server có các ích lợi sau:

Team build từ các remote team ảnh hưởng đến các team's build server, chứ không phải tăng việc load trên các internal build server.
Các remote builds cung cấp các tập tin nhị phân(binary) cho các remote team, mà không cần to truyền các tập tin binary qua mạng.

Không sử dụng các remote build server như là một sự thay thế hoàn toàn cho các build được khởi tạo trên internal build server. Thậm chí nếu các remote build được khởi tạo từ các source code version giống nhau như là các internal build, bạn phải thấy các trạng thái khác nhau bởi vì cấu hình các build hay source khác nhau giữa các server. Như là một sự hướng dẫn, kiểm thử quan trọng cơ bản trên các internal build, đặc biệt là khi bạn gần phát hành.

Note: Tầng application giao tiếp với các build server trên port 9191. Nếu bạn có một remote build server, hãy cài đặt firewall của bạn để tầng application có thể connect trên port này.

Tóm tắt

Nếu bạn đang sử dụng TFS mà không có SP1, hãy sử dụng một VPN để tạo các kết nối từ xa remote access. Nếu bạn đang sử dụng TFS SP1, thì bạn có thể sử dụng Basic authentication over SSL để đặt TFS của bạn trên extranet của bạn, hay bạn có thể cho các kết nối truy cập thông qua một reverse proxy.

Nếu bạn muốn cải thiện hiệu suất truy cập từ xa, đặc biệt là trên các VPN scenario, bạn có thể install và cấu hình TFS Proxy để lưu trữ các file source control trong remote location.

Tài nguyên bổ sung

Để có thêm thông tin về cài đặt TFS cho remote development, hãy xem "Walkthrough: Setting up TFS for a Remote Development Location" tại http://msdn2.microsoft.com/en-us/library/ms242919(VS.80).aspx
Để có thêm thông tin về cài đặt TFS với SSL, hãy xem "Walkthrough: Setting up Team Foundation Server with Secure Sockets Layer (SSL)" tại http://msdn2.microsoft.com/en-us/library/ms242875(VS.80).aspx
Để có thêm thông tin về TFS Basic và Digest authentication, hãy xem "Team Foundation Server, Basic Authentication, and Digest Authentication" tại http://msdn2.microsoft.com/en-us/library/aa833874(VS.80).aspx
Để có thêm thông tin về TFS Proxy, hãy xem"Team Foundation Server Proxy and Source Control" tại http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx
Để có thêm thông tin về managing the TFS Proxy, hãy xem "Managing Remote Connections to TFS Proxy" tại http://msdn2.microsoft.com/en-us/library/ms253156(VS.80).aspx
Để có thêm thông tin về troubleshooting the TFS Proxy, hãy xem "Troubleshooting TFS Server Proxy" tại http://msdn2.microsoft.com/en-us/library/ms400681(VS.80).aspx
Để có thêm thông tin về examining TFS Proxy performance, hãy xem http://msdn2.microsoft.com/en-us/library/ms252455(VS.80).aspx

Chương 16 - Team Foundation Server Deployment

Nguyễn Thị Như Quỳnh — Tue, 08 Dec 2009 08:58:35 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/8/2009 4:58:35 PM

Phần VIII

Thiết lập và Duy Trì Môi trường Nhóm

Trong phần này

Triển khai Team Foundation Server
Truy cập đến Team Foundation Server bằng Internet

Chương 16 - Team Foundation Server Deployment

Chủ đề

Tìm hiểu về những lợi ích và bất lợi của việc triển khai single-server và multiple-server .
Chọn lựa triển khai một cấu trúc liên kết(topology) phù hợp với các yêu cầu của tổ chức của bạn.

Xem trước

Chương này vạch ra các phương pháp chính để triển khai Microsoft ® Visual Studio ® 2005 Team
Foundation Server (TFS) và mô tả các điểm quyết định chính mà bạn sẽ phải đối mặt khi triển khai TFS tại tổ chức của bạn. Chương này giải thích hai lựa chọn triển khai và miêu tả bằng cách nào lựa chọn giữa những tùy chọn.

Có hai tùy chọn để triển khai TFS, single-server và dual-server installation. Một single-server installation đặt tại tầng data và tầng application trên một single server. Một dual server installation chia đôi tầng application và tầng data vào các server khác nhau. Ngoài ra, bạn có thể install build server và source control proxy trên các server khác nhau. Mỗi client yêu cầu truy cập đến các server và các client-side tool tương ứng phải được install.

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

Sử dụng chương này để xác định chiến thuật triển khai TFS của bạn. Để đạt được lợi ích tốt nhất từ chương này, bạn nên:

Tìm hiểu kiến trúc TFS. Hãy chắc là bạn đã tìm hiểu đầy đủ về cấu trúc TFS architecture. Nếu bạn không quen với kiến trúc của Team Foundation Server hãy đọc phần "TFS Architecture" , hay đọc "Chương 2 - Kiến trúc Team Foundation Server " để có thêm thông tin.
Chọn một chiến thuật triển khai. Chọn một chiến thuật triển khai phù hợp nhất đối với nhu cầu của tổ chức bạn. Nếu bạn chưa làm như thế, hãy đọc phần "Deployment Scenarios" để xác định chiến thuật triển khai(deployment strategy) nào sẽ làm việc tốt nhất với nhóm bạn.

Kiến trúc TFS

Hình 16.1 trình bày kiến trúc TFS architecture.

Cấu trúc TFS được thành lập bởi ba tầng, tầng data, tầng application và tầng client. Những tầng này được chia ra rất logic, và tất cả ba tầng đều được install trên cùng một computer.

Tầng Team Foundation data bao gồm Microsoft SQL Server^TM 2005. Một số các databases được install mà lưu trữ các work item, version control system, các test result và bất cứ report nào.

Tầng application chứa một Web-based front end được tích hợp vào Internet Information Services (IIS), Team Foundation Web services, và Microsoft Office SharePoint® services. Tầng application cũng chứa bất kì build servers và source control proxy servers nào.

Tầng client chứa các ứng dụng mà kết nối đến TFS. Developers sử dụng Team Explorer để kết nối đến Team Server, install cả một stand-alone tool hay như một phần của Visual Studio 2005. Project Managers sử dụng Microsoft Office Excel® hay Microsoft Office Project. Bạn cũng có thể sử dụng third-party tool(công cụ của bên thứ ba cung cấp) để kết nối đến server.

Để có thêm thông tin, hãy xem "Chapter 2 - Team Foundation Server Architecture."

Các kịch bản triển khai

Bạn có thể triển khai TFS theo các cách sau:

Triển khai Single-server

Cùng với một workgroup.

Sử dụng Microsoft Active Directory ® directory service.

Triển khai Dual-server

Triển khai Single-Server với Workgroup

Với phương pháp triển khai này, bạn tạo một workgroup ở nơi mà bạn không có Active Directory domain controller. Bạn sử dụng chế độ installation khi bạn có một nhóm nhỏ. Nếu bạn sử dụng chế độ installation này, mỗi user yêu cầu một local account trên server để cho phép họ đăng nhập (log on) vào server. Đối với loại triển khai này, bạn có thể chỉ cần install trên một single-server, và dual-server installation không được hỗ trợ.

Triển khai Single-Server với Active Directory

Nếu bạn có một Active Directory, sau đó bạn có hai lựa chọn triển khai. Bạn có thể install cả tầng data và tầng application trên cùng một server, hay bạn có thể install tầng data và tầng application trên những server riêng biệt.

Các loại triển khai nào đúng cho tổ chức của tôi?

Để quyết định install một single-server hay dual-server là lựa chọn đúng cho tổ chức của bạn, hãy xem xét các câu hỏi sau:

Có bao nhiêu users mà tôi cần support? Nếu bạn dự tính có hơn 400 users, hãy xem xét triển khai dual-server để phù hợp hơn với nhu cầu của tổ chức bạn.
Có bao nhiêu project tôi sẽ support với TFS? Nếu bạn đang hỗ trợ một số lớn các project, hãy xem xét triển khai một dual-server TFS có phù hợp với nhu cầu kinh doanh của bạn hay không. Mỗi TFS instance có thể hỗ trợ lên đến 5000 project. Nếu bạn cần để hỗ trợ hơn 5000 project thì hãy xem xét việc thiết lập nhiều Team Foundation Server instance.
Có phải tôi có một server mà tôi có thể dành cho TFS? Server trong một single-server Team Foundation Server deployment nên được dành riêng cho các TFS functionality. TFS không nên phục vụ cho bất kì mục đích nào khác, như là mail server, file server, hay là database server cho các ứng dụng khác.

Lợi ích của việc triển khai Single-Server

Hãy cân nhắc các lợi ích sau khi quyết định có nên thực hiện triển khai một single-server :

• Đơn giản

Ø Bạn có thể quản lý tất cả các khía cạnh của sự triển khai TFS trên một single-server.

Ø Bạn có thể cấu hình tất cả các quyền truy cập và permission cho các user và các group trên cùng một server.

Ø Bạn chỉ có một server để lên lịch cho việc backup và bảo trì.

• Có lợi Bởi vì cả tầng application và tầng data đều có trên một single server, bạn không phải xem xét network restrictions hay network latency giữa tầng application và tầng data khi lên kế hoạch triển khai.

Lợi ích của việc triển khai Dual-Server

Hãy cân nhắc các lợi ích sau khi quyết định thực hiện việc triển khai một dual-server:

Scalability. Triển khai single-server được thiết kế lên đến 400 users, trong khi triển khai một dual-server sẽ cho phép bạn đưa quy mô này vượt lên giới hạn là 2000 users.
Fail-over. Bạn có thể chuyển hướng tầng application server đến một tầng data server khác trong trường hợp bảo trì hay sữa chữa, và bạn không thế cấu hình hay triển khai một server bổ sung mà có thể hoạt động như một standby server hay fail-over application-tier server.

Triển khai Single-Server

Hình 16.2 trình bày một triển khai single server điển hình. Install trên một server là các tầng TFS application và data , cùng với SharePoint Services và SQL Server 2005.

Triển Khai Dual-Server

Hình 16.3 hiển thị cài đặt một dual server điển hình. Tầng TFS application được install cùng với SharePoint Services trên một tầng. Tầng TFS data được install bên cạnh SQL Server 2005 trên server khác.

Các Server khác

Trong việc cài đặt single-server cả dual-server , bạn có thể install một build server riêng biệt như là một proxy server. Những cái này có thể được install lên cùng server như là tầng application hay trên các server khác.

Cài đặt Build Server

Bạn có thể xác định vị trí của build service của bạn trên một separate server để cải thiện hiệu suất build và giảm việc load trên tầng application. Thí dụ, nếu hiệu suất server tầng application của bạn bị ảnh hưởng bởi các frequent builds, hãy xem xét việc di chuyển các build services đến một separate server.

Team Foundation Proxy Server

Team Foundation proxy server lưu trữ các bản sao của source control files. Bạn nên sử dụng proxy server nếu bạn đang truy cập đến source control server trên một network có độ trễ(latency) cao.

Team Foundation Server Topologies

Sau khi bạn đã quyết định cài đặt hoặc là single-server hoặc là dual-server , có một vài topology(cấu trúc liên kết) mà bạn có thể sử dụng. Vùng Topology từ đơn giản đến phức tạp. Mỗi topology được thiết kế cho những kích cỡ nhất định của các nhóm phát triển.

Simple Topology

Hình 16.4 hiển thị một topology đơn giản nơi mà các thành phần của tầng TFS application và tầng data được triển khai trên một single server. TFS proxy server được triển khai đến một separate server. Server có thể truy cập được từ client workstations trên cùng domain.

Sự cấu hình này thích hợp cho các nhóm phát triển hay các pilot project với lên đến 400 users.

Moderate Topology

Hình 16.5 trình bày TFS được install lên các tầng khác nhau. Application services được triển khai lên một node của tầng application và các database lên một node riêng biệt của tầng data.

Hình 16.5 Moderate Team Foundation Server Topology

Hình 16.5 cũng trình bày một test rig và một số các build servers được triển khai trên các node riêng biệt. Các node client có cả trong cùng một domain như là các server hay trong domain mà có một mối quan hệ tin cậy với các server. Các Topology phức tạp này là những mục tiêu của các nhóm phát triển rất lớn trong khoảng từ 400 đến 2000.

Complex Topology

The complex topology được hiển thị trong Hình 16.6 tương tự như moderate topology. Tuy nhiên, trong những thành phần topology fail-over này đã được thêm vào một tầng application standby server và một tầng data với các SQL clustering technologies.

Hình 16.6 cũng trình bày một domain con khoảng cách xa mà sử dụng một limited-bandwidth connection. Những client này sử dụng TFS proxy server để cải thiện thời gian truy cập đến source control.

Tài nguyên bổ sung

Khi triển khai TFS hãy xem xét những điều sau:

Nếu bạn đã có một SharePoint server thiết lập và muốn sử dụng nó để lưu trữ Team Foundation Server SharePoint site của bạn, bạn có thể di chuyển TFS SharePoint site đến server khác.Để có thêm thông tin, hãy xem http://blogs.msdn.com/bharry/archive/2006/10/30/moving-your-tfs-sharepoint-site.aspx
Di chuyển OLAP engine và cube đến một máy thứ ba để chứng tỏ có lợi cho các nhóm lớn hơn. Bạn có thể cài đặt SQL clustering trên tầng data , và có một active/active configuration với SQL trên một node, và OLAP trên cái khác, mỗi acting cũng như failover cho cặp của nó. Để có thêm thông tin, hãy xem: http://msdn2.microsoft.com/en-us/library/aa721760(vs.80).aspx và http://msdn2.microsoft.com/en-us/library/ms252505(VS.80).aspx

Chiến thuật Team Foundation Server Scaling và Backup

Như một phần của tiến trình cài đặt và triển khai Team Foundation Server của bạn, bạn phải quyết định bạn sẽ quản lý backup và failover của các server của bạn như thế nào. Các chiến lược backup và failover bạn chọn dựa vào kích cỡ của tiến trình cài đặt và các thiết bị và nguồn lực sẵn có của tổ chức bạn. Bởi vì tầng data được build trên SQL Server 2005 các chiến lược mà bạn đã áp dụng được dựa trên các phương pháp bạn đang làm để backup SQL Server.

Nếu bạn hiện đang phản ánh hoặc nhóm các cái đặt SQL Server 2005 thì sau đó bạn có thể dùng cùng một cách tiếp cận với tầng TFS data. Bạn cũng cần quyết định làm cách nào quản lý các failure của tầng application server. Nếu bạn muốn hỗ trợ tầng application failover, bạn sẽ cần một server backup tầng application tại chỗ và phải có khả năng thông qua server một cách nhanh chóng.

Chọn một chiến thuật Installation và Backup/Recovery phù hợp cho công ty của bạn.

Khi install TFS bạn cần thực hiện một số lựa chọn về sự cài đặt và các chiến thuật backup/recovery . Hãy xem xét các điều sau khi quyết định cho chiến thuật cài đặt của bạn:

Size of teams :Kích cỡ của các nhóm
Number of projects : Số các project
Size of projects : Kích cỡ của các project
Location of teams : Vị trí của các team
Failover needs :Nhu cầu failover
Backup needs: Nhu cầu backup

Đề nghị phần cứng Team Foundation Server

Nhìn chung, các nhóm nhỏ hơn với số lượng project ít hơn có thể chạy trên một single tier installation, trong khi các nhóm lớn hơn yêu cầu các dual tier và phần hardware nhanh hơn. Sự lựa chọn của single-tier so với dual-tier installation cũng ảnh hưởng đến cơ chế backup và failover của bạn.

Sử dụng Table 16.1 để giúp bạn quyết định cài đặt trên một single-tier hay dual-tier và để xác định nhu cầu hardware cần thiết để hỗ trợ cho nhóm của bạn.

Bảng 16.1 Yêu cầu phần cứng để triển khai TFS

Backup và Failover Strategy

Khi xem xét chiến lược backup và failover của bạn, bạn cần lưu ý đến sự ảnh hưởng của việc mất đi một server lên năng suất của nhóm bạn.

Backup

Bạn cần lên kế hoạch cho chiến lược backup của bạn như một phần của sự triển khai việc cài đặt TFS. Bạn cần xem xét:

Tần số sao lưu dữ liệu.
Tần số sao lưu đầy đủ và gia tăng.
Yêu cầu lưu trữ cho việc backup, ví dụ như on-site và off-site backup.

Bạn có thể sử dụng cùng một tiêu chuẩn thực hành mà bạn đã sử dụng cho các database của SQL Server 2005.

Bạn có thể sử dụng các backup để restore TFS theo ba kịch bản sau:

Data-only recovery.
Single-server deployment full recovery.
Dual-server deployment full recovery.

Data-only recovery được sử dụng nếu tầng data bị corrupt. Bạn có thể sử dụng backup data và logs để phục hồi toàn bộ database.

Server recovery được sử dụng khi các server fail. Trong trường hợp này, bạn có thể restore toàn bộ database vào một computer thứ hai.

Application-Tier Standby Server

Mặc dù không có data để backup trên các server tầng application, các server có thể vẫn còn fail. Để giảm thiểu chi phí của sự thất bại này, bạn nên xem xét một warm standby server để cho phép failover trên tầng application.

Failover

Khi xem xét việc cung cấp một failover solution cho TFS của bạn, bạn nên xem xét chi phí cho nhu cầu phần cứng để cung cấp các failover servers dựa vào chi phí của những năng suất bị mất(lost productivity) của công ty của bạn nếu TFS không khả dụng.

Failover thêm vào sự phức tạp cho sự cài đặt của bạn với thêm vào các chi phí bảo trì. Bạn phải xem phần chi phí cho sự bảo trì này như là một nhân tố vào các cân nhắc về chi phí khi quyết định trên chiến lược của bạn.

Clustering có chi phí cao về các nguồn resource và bảo trì và được khuyến khích nếu tổ chức của bạn đã được cung cấp các nguồn resource để quản lý một clustered server.

Mirroring có một mức chi phí, nhưng không cao như clustering. Mirroring có lợi thế là cho phép bạn để có các server offline chính cho việc bảo trì(maintenance). Bạn nên xem xét đến mirroring nếu tổ chức của bạn có thể cài đặt và bảo trì một server tầng data thứ hai.

Tầng Data

Clustering the Data-Tier Servers

Nếu tổ chức của bạn có những resources cần thiết, bạn nên xem xét cài đặt các server chuyên dành riêng trong một cluster. Cluster sẽ cung cấp sự truy cập không bị gián đoạn đến tầng data. Lưu ý là, tuy nhiên, các yêu cầu phần cứng đó cho một cluster là đòi hỏi hơi nhiều. Chi phí các điều kiện của resources của việc thiết lập và bảo trì một cluster thì cao.

Khi clustering, TFS hỗ trợ một cấu hình với một passive node, một active node và một single quorum device server. Khi tầng data không vượt qua được passive node, node này sẽ có quyền sở hữu đại diện và sở hữu tầng data.

Bạn cần chuẩn bị cluster cho việc installation trước khi installing TFS trong một cluster. Để có thêm thông tin về SQL Server 2005 clustering, download the "SQL Server 2005 Failover Clustering White Paper" tại http://www.microsoft.com/downloads/details.aspx?familyid=818234dc-a17b-4f09-b282-c6830fead499&displaylang=en

Mirroring Server Tầng Data

Mirroring một server liên quan đến việc đồng bộ dữ liệu trên một server với một bản sao copy của data đó trên server khác. Server tầng data là server chính, và server với mirrored data là server backup hay mirroring server. Nếu server tầng data của bạn thất bại, bạn có thể tự chuyển đổi sang mirrored server.

Có một mirrored server cho phép bạn sử dụng server offline chính cho việc bảo trì và sữa chữa, và cũng để cung cấp một cơ chế phục hồi nhanh nếu server chính tầng data của bạn bị fail.

Mirroring vừa có thể đồng bộ vừa có thể bất đồng bộ. Bạn có thể trao đổi các server từ server chính đến mirror server trong một cơ chế di chuyển được gọi là role switching(quy luật dịch chuyển). Khi một role switch xảy ra, mirror sẽ mất vai trò là server chính. Nếu server chính vẫn còn giữ vai trò của nó, nó sẽ giành lấy vai trò của mirror. Về nguyên tắc, các vai trò có thể chuyển đổi qua lại.

Đối với TFS, việc tự động chuyển đổi không được hỗ trợ và thay vào đó thì bạn phải tự chuyển đổi.

Để cấu hình SQL Mirroring cho tầng Data

1. Thực hiện backup toàn bộ các databases và transaction log.

2. Backup the Reporting Services encryption key.

3. Install SQL Server 2005 trên mirror server.

4. Restore the data từ tầng data trên mirror server.

5. Với mỗi database trên tầng data ở server chính, chạy Configure Database Mirroring Security Wizard để cấu hình mirror server của nó.

6. Start mirroring.

Failing qua một Mirrored Server

Bạn phải fail over bằng tay mirrored server bằng cách thực hiện các bước sau:

1. Trên TFS tầng application

a. Cấu hình lại the Report Service để sử dụng server mới.

b. Stop the default Web site.

c. Stop the SharePoint Web site.

d. Stop the SharePoint Timer service.

e. Stop the TfsServerScheduler service.

f. Stop the ReportServer application pool.

g. Stop the TFS App Pool application pool.

2. Trên mirror data-tier server hãy chắc là các correct service accounts đã được add.

3. Fail over mỗi database từ server chính đến mirroring server.

4. Build the data warehouse trên server mới.

5. Cấu hình server tầng application để sử dụng server tầng mirror như sau:

a. Từ một command prompt, run TFSAdminUtil RenameDT MirrorDataTierServer.

b. Restart IIS.

c. Thay đổi Reporting Services connection strings để reference the mirror data-tier server.

d. Thay đổi SharePoint server để sử dụng mirror data-tier server

e. Start the SharePoint timer service.

f. Start the TfsServerScheduler service.

g. Start the ReportServer application pool.

h. Start the TFS App Pool application pool.

i. Start Reporting Services.

j. Gọi dẫn ra StampWorkItemCache Web service.

Tầng Application

Failover tầng Application

Sau khi cài đặt server chính tầng application, bạn có thể thêm một warm standby computer để cho phép một warm failover của tầng application.

Standby Hardware và Software

Standby server không cần phải giống hệt như server chính, nhưng nó cần phù hợp với các yêu cầu hardware cho tầng application. Bạn install TFS application-tier software trên warm standby server.

Bạn phải đảm bảo là cả hai server đều có cấu hình như nhau, bao gồm cả user accounts, permission changes, và software updates. Bất kì update nào trên computer chính cũng cần phải được áp dụng trên warm standby server.

Để minimize bất kì problem nào với failover, bạn phải cấu hình network adapters để sử dụng cùng host name từ hai standby computer và các computer chính. Có rất nhiều cách để thực hiện điều này.

Failing qua Server tầng Application

Bạn fail over bằng tay server tầng application . Khi server chính fails, bạn phải hoàn thành các bước để activate bằng tay warm standby server. Bạn có thể chạy TFSAdminUtil utility passing the ActivateAT command, trên standby server, để giúp fail over trên server chính.

Để warm fail over the server:

1. Lảm cho server gốc offline khi chế độ standby của server tầng application được kích hoạt

2. Trên standby server

a. Log vào với quyền administrator.

b. Chạy TFSAdminUtil qua ActivateAT

c. Khởi động Web services trên standby server.

Lệnh này sẽ

Đăng kí tên của warm standby server trong TFS integration database.
Kết nối warm standby tầng application server đến active tầng data server.
Xác nhận đúng server tầng application được kết nối chính xác đến server tầng data.

Để có thêm thông tin về làm thế nào để activate một application-tier failover server, hãy xem "How to: Activate a Fail-Over Application-Tier Server" tại http://msdn2.microsoft.com/en-us/library/ms252501(VS.80).aspx

Tổng Kết

Cấu trúc TFS có ba tầng: một tầng application, một tầng data, và một tầng client. Khi bạn install the server, bạn có thể chọn để install tầng application và tầng data trên cùng một server hay trên các server riêng biệt. Sự lựa chọn triển khai TFS của bạn chủ yếu phụ thuộc vào số lượng người sử dụng mà bạn muốn hỗ trợ. Sau khi bạn đã chọn một topology hỗ trợ nhưng nhu cầu của nhóm bạn, bạn có thể quyết định mức độ hỗ trợ của việc backup và failover mà bạn cần.

Đối với tầng data, bạn có thể sử dụng cùng một cơ chế backup mà tở chức của bạn sử dụng cho các SQL Server 2005 backup khác của bạn. Đối với hỗ trợ failover, bạn có thể chọn để mirror hay cluster các server tầng data.

Tầng application không hỗ trợ tự động failover. Nếu bạn muốn hỗ trợ rapid failover, bạn có thể cung cấp một warm failover server mà bạn có thể tự thực hiện fail over.

Tài nguyên bổ sung

Để có thêm thông tin về installing TFS, hãy xem Visual Studio 2005 Team Foundation Installation Guide tại http://go.microsoft.com/fwlink/?linkid=40042
Để có thêm thông tin về TFS scalability limits, hãy xem "Team Foundation Server Capacity Planning" tại http://blogs.msdn.com/bharry/archive/2006/01/04/509314.aspx
Để có thêm thông tin về làm thế nào để di chuyển OLAP cube và analysis engine đến một separate server, hãy xem "How To: Move the Data Warehouse SQL Server Analysis Services Database to a Separate Server" tại http://msdn2.microsoft.com/en-us/library/aa721760(vs.80).aspx
Để có thêm thông tin về SQL Server 2005 clustering download "SQL Server 2005 Failover Clustering White Paper" tại http://www.microsoft.com/downloads/details.aspx?familyid=818234dc-a17b-4f09-b282-c6830fead499&displaylang=en
Để có thêm thông tin về khởi tạo một SQL Server failover cluster hãy xem "How To: Create a New SQL Server 2005 Failover Cluster (Setup)" tại http://uat.technet.microsoft.com/en-us/library/ms179530(SQL.90).aspx
Để có thêm thông tin về làm thế nà để cài đặt một SQL Server cluster cho tầng data của bạn, hãy xem "Clustering the Data-Tier Server" tại http://msdn2.microsoft.com/en-us/library/ms252505(VS.80).aspx
Để có thêm thông tin về làm thế nào để di chuyển TFS SharePoint site đến server khác, hãy xem"Moving your TFS SharePoint site" tại http://blogs.msdn.com/bharry/archive/2006/10/30/moving-your-tfs-sharepoint-site.aspx
Để có thêm thông tin về Team Foundation Server Scalability, hãy xem Brian Harry's blog tại http://blogs.msdn.com/bharry/archive/2005/12/09/502190.aspx
Để có thêm thông tin về planning cho disaster recovery hãy xem "Visual Studio Team System User Education" tại http://www.microsoft.com/technet/itshowcase/content/vs05teamsystemnote.mspx
Để có thêm thông tin về backup failure và recovery của một Team Foundation Server, hãy xem"Ensuring Team Foundation Server Availability" tại http://msdn2.microsoft.com/en-gb/library/ms253159(VS.80).aspx
Để có thêm thông tin về clustering server tầng data, hãy xem "Clustering the Data-Tier Server" tại http://msdn2.microsoft.com/en-gb/library/ms252505(VS.80).aspx
Để có thêm thông tin về mirroring Team Foundation Server tầng data, hãy xem "Mirroring the Team Foundation Data-Tier Server" tại http://msdn2.microsoft.com/en-gb/library/aa980644(VS.80).aspx

Để có thêm thông tin về cấu hình SQL Server mirroring cho tầng data, hãy xem "How to: Configure SQL Server Mirroring for the Team Foundation Data-Tier Server" tại http://msdn2.microsoft.com/en-us/library/aa980629(VS.80).aspx

Để có thêm thông tin về failing over tầng data, hãy xem "How To: Fail Over to a Mirrored Data-Tier Server" tại http://msdn2.microsoft.com/en-gb/library/aa980627(VS.80).aspx
Để có thêm thông tin về failing over tầng data if the principle server is unavailable, see "How To: Fail Over to a Mirrored Data-Tier Server if the Principal Data-Tier Server is Unavailable" tại http://msdn2.microsoft.com/en-gb/library/aa980528(VS.80).aspx
Để có thêm thông tin về làm cách nào để activate một tầng application fail over server, hãy xem "How To: Activate a Fail-Over Application-Tier Server" tại http://msdn2.microsoft.com/en-us/library/ms252501(VS.80).aspx
Để có thêm thông tin về activating an application tier fail over server, hãy xem "Activating a Fail-Over Application-Tier Server" tại http://msdn2.microsoft.com/en-us/library/ms252486(VS.80).aspx

Chương 15 – Giải thích về Report

Nguyễn Thị Như Quỳnh — Tue, 08 Dec 2009 08:30:45 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/8/2009 4:30:45 PM

Chương 15 – Giải thích về Report

Chủ đề

Miêu tả kiến trúc Microsoft® Visual Studio® Team Foundation Server (TFS) reporting .
Xác định các thành phần tạo nên TFS reporting.
Miêu tả mục đích của từng report có sẵn.
Tìm hiểu process template nào chứa đựng report nào.
Tùy chỉnh và tạo mới các report.

Xem trước

Chương này miêu tả kiến trúc của TFS reporting và các report thông thường mà bạn có thể sử dụng với các team project mới. Còn kết nối các kịch bản báo cáo chung với các kịch bản có sẵn trong TFS, và miêu tả các nguyên nhân chung nhất dẫn đến việc tùy chỉnh các report đã có hay tạo mới các report. TFS reporting cho phép bạn xem dữ liệu tổng hợp trên nhiều khía cạnh của team project của bạn. Bạn có thể sử dụng thông tin này để phân tích tiến độ dự án, tình trạng project , và hiệu suất làm việc của những đội ngũ phát triển và kiểm thử của bạn.

TFS reporting sử dụng Microsoft SQL Server^TM 2005 Reporting Services để tạo, quản lý và chạy các reports. Mỗi process template chứa một tập các report chưa xác định trước(predefined reports) được triển khai đến thư mục report của dự án khi mà dự án được tạo. Bằng cách sử dụng Reporting Services bạn cũng có thể sửa đổi các report này và tạo các report tùy ý cho project của bạn. Bạn có thể thêm mới các report cho một process template đã có để dự trữ sẵn cho các team project khác.

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

Sử dụng chương này để tìm hiểu TFS reporting làm việc như thế nào và bằng cách nào mà nó có thể giúp bạn đánh giá tình trạng và chất lượng của project. Để có được lợi ích tốt nhất từ chương này, bạn nên:

Đọc phần "Scenarios and Solutions". Tìm hiểu những nguyên nhân thông thường để sử dụng TFS reporting và nghiên cứu mục đích của từng chuẩn report.
Đọc phần "Physical Architecture" . Nghiên cứu thành phần nào tạo nên reporting system và chúng tương tác với nhau như thế nào
Đọc phần "Customizing Reports" . Nghiên cứu cơ chế sẵn có cho sự tùy chỉnh và khởi tạo report.
Đọc chủ đề Làm thế nào kèm theo. Đọc các chủ đề Làm thế nào được đi kèm sau đây để để đi qua từng bước các thảo luận trong chương này.

o Làm thế nào - Tùy chỉnh một Report với Visual Studio 2005 Team Foundation Server"

o Làm thế nào - Tạo một Custom Report trong Visual Studio 2005 Team Foundation Server

o Làm thế nào - Tạo một Risk Over Time Report với Visual Studio 2005 Team Foundation Server

Tình huống và giải pháp

Report là phương pháp chính để các project manager và các team leader theo sát một project đang được triển khai. Sau khi bạn tạo mới một team project, một tập các report được khởi tạo cho bạn dựa trên mẫu quy trình mà bạn chọn. Những report này có sẵn cho bạn từ các project's Microsoft Office SharePoint® portal site hay từ các report node trong Team Explorer ở bên trong Visual Studio.

Sau đây là những câu hỏi phổ biến khi sử dụng TFS reports có thể trả lời được:

Khi nào ứng dụng của tôi sẵn sàng được vận chuyển?
Có phải tiến hành công việc theo kế hoạch?
Chất lượng của build là gì?
Tình trạng phát triển tùy vào việc xác định các tình huống, kịch bản định trước là gì?

• Làm thế nào hoàn thành công việc phát triển một cách nhanh chóng?

Có phải các lỗi cố định không?
Có phải là các bug đang được giảm bớt?

Team Foundation Server Reports

Cả hai Microsoft Solution Framework (MSF) for Agile Software Development (MSF Agile) và MSF for CMMI® Process Improvement (MSF CMMI) process templates thì mỗi bên đều có một tập các report mặc định có sẵn.

Bugs

Các bug liên quan đến các report trong các quy trình mẫu cho phép bạn nhìn thấy loại nào của các bug đã đang được tạo và sữa chữa và để xác định các xu hướng. Sau đây là các bug liên quan đến các report có sẵn:

Bugs by Priority. Là các correct bug sẽ được tìm thấy? Report này hiển thị cho bạn tỉ lệ của các high-priority bugs(lỗi có độ ưu tiên cao) được tìm thấy so với các low priority bugs(lỗi có độ ưu tiên thấp). Report này có sẵn trong cả hai quy trình mẫu được cung cấp.
Bug Rates. Làm cách nào mà các bug đang được tìm kiếm, sữa chữa và kết thúc nó một cách hiệu quả?Report này chỉ ra các xu hướng theo thời gian của các lỗi mới(new bug), bug backlogs(lỗi về truyền tải thông tin), và bug resolution(lỗi về độ phân giải màn hình). Report này có sẵn trong cả hai quy trình mẫu được cung cấp.

Release Management

Release management report(Các báo cáo quản lý các phiên bản phát hành) cho phép bạn xem xét phần mềm của bạn sẽ kết thúc một cách phù hợp như thế nào để phát hành. Sau đây là các release management reports có sẵn:

Actual Quality versus Planned Velocity. Có bao nhiêu kịch bản được hoàn thành trước khi chất lượng không được chấp nhận? Report này trình bày các mối quan hệ của từng iteration, của kích cỡ ước lượng về chất lượng tổng thể. Report này có sẵn trong cả hai quy trình mẫu được cung cấp.
Builds. Quality of build là gì? Report này cung cấp một danh sách các build có sẵn bao gồm build quality và các thông tin chi tiết khác. Report này có sẵn trong MSF for CMMI Process Improvement.
Quality Indicators. Chất lượng phần mềm là gì? Report này tống kết các kết quả kiểm thử, các lỗi, code coverage và code churn vào một single report để theo dõi project health. Report này có sẵn trong MSF Agile và MSF CMMI.
Velocity. Làm thế nào nhóm có thể nhanh chóng hoàn thành công việc? Report này trình bày bằng cách nào mà nhóm có thể hoàn thành kế hoạch công việc và chỉ ra tỉ lệ thay đổi từ ngày này sang ngày khác. Report này có sẵn trong MSF Agile và MSF CMMI.
Scenario Details. Chúng ta thiết kế ứng dụng dựa trên kịch bản nào? Report này cung cấp thông tin trên mỗi kịch bản bao gồm completion status(tình trạng hoàn thành), risks(các rủi ro) và testing progress(tiến độ kiểm thử). Report này có sẵn trong MSF CMMI.

Testing

Kiểm thử reports cho phép bạn giám sát hiệu quả và tiến độ của các kiểm thử của bạn. Sau đây là các kiểm thử report(test report) có sẵn:

Regressions. Những kiểm thử nào đã qua được một mốc nhưng bây giờ lại thất bại?Report này trình bày một danh sách tất cả các kiểm thử đã thành công trước đó nhưng bây giờ thất bại. Report này có sẵn trong MSF CMMI.
Requirements Test History. Kiểm thử tốt như thế nào cho các kịch bản và các yêu cầu của tôi?Report này trình bày tiến độ kiểm thử dựa vào việc xác định các kịch bản và các yêu cầu. Report này có sẵn trongg MSF CMMI.
Test Failure Without Active Bug. Có phải có các lỗi để theo dõi các khuyết tật? Report này trình bày bất cứ kiểm thử nào đã thất bại và không được liên kết với một open bug. Report này có sẵn trong MSF CMMI.
Test Passing With Open Bug. Có phải danh sách lỗi(bug list) được cập nhật liên tục và nhất quán với chất lượng của ứng dụng? Report này trình bày các lỗi cũ mà các kiểm thử bây giờ đang được kiểm thử là vượt qua. Report này có sẵn trong MSF CMMI.
Load Test Tổng Kết. Kết quả của việc load các kiểm thử trên việc thi hành ứng dụng là gì?Report này trình các kết quả kiểm thử cho việc load các kiểm thử trên ứng dụng của bạn.Report này có sẵn trong MSF Agile.

Work Items

Work item reports cho phép bạn đánh giá tình trạng hiện tại của dự án và của tiến độ hiện tại của dự án của bạn. Sau đây là các work item reports có sẵn:

Open Issues and Blocked Work Items Trend. Còn bao nhiêu open issues? Report này trình bày các open issues còn tồn tại cũng như là xu hướng để giải quyết chúng. Report này có sẵn trong MSF CMMI.
Reactivations. Có bao nhiêu work items đang được tái kích hoạt? Report này trình bày các work items đã được giải quyết hay kết thúc sớm. Report này có sẵn trong MSF Agile and MSF CMMI.
Related Work Items. Các work item này phụ thuộc vào các work items khác là gì? Report này trình bày một danh sách các work item liên kết với các work item khác để bạn theo dõi các sự phụ thuộc(dependency). Report này có sẵn trong MSF CMMI.
Remaining Work. Có bao nhiêu công việc vẫn còn đang làm và khi nào kết thúc công việc ấy?Report này trình bày các công việc còn lại , được giải quyết và kết thúc theo thời gian. Lên kế hoạch trước các công việc còn lại cho phép bạn dự đoán thời điểm mà bạn sẽ hoàn thành code của bạn. Report này có sẵn trong MSF Agile và MSF CMMI.
Triage. Các work item nào cần được chọn để thực hiện theo kế hoạch(triage)? Report này trình bày tất cả các work item vẫn đang ở trong tình trạng đề xuất. Report này có sẵn trong MSF CMMI.
Unplanned Work. Có bao nhiêu công việc không được dự tính trước? Report này lập biểu đồ tổng các công việc so với các công việc còn lại và phân biệt các công việc có kế hoạch từ các công việc không có kế hoạch. Report này có sẵn trong MSF Agile và MSF CMMI.
Work Items. Các active work items là gì? Report này liệt kê tất cả các active work item. Report này có sẵn trong MSF CMMI.
Work Items by Owner. Có bao nhiêu công việc được phân chia cho từng thành viên của nhóm? Report này trình bày các work item trên mỗi thành viên của nhóm. Report này có sẵn trong MSF CMMI.
Work Items by State. Có bao nhiêu active, resolved và closed work items ở đây? Report này liệt kê các work items được tổ chức bởi các state. Report này có sẵn trong MSF CMMI.

Tùy chỉnh các Report

Bạn có thể cần một report mà không có trong các MSF process templates. Thì bạn có thể tùy chỉnh các reports bằng một trong ba cách sau đây:

Use a filter on an existing report. Rất nhiều report cung cấp các tham số mà bạn có thể sử dụng để lọc các report. Thí dụ date, area, iteration, và các priority filters(lọc ưu tiên) có sẵn. Sử dụng những filter(bộ lọc) này để xem lại một tập hợp các data được cung cấp trong report. Hãy lưu ý là những filter này chỉ có tính chất tạm thời và sẽ bị mất đi khi bạn không duyệt các report nữa.
Customize an existing report. Nếu một report bạn muốn tương tự như một report đã có, thường thì dễ nhất là copy report đã có và sau đó chỉnh sửa nó. Thí dụ, bạn có thể muốn phân chia các rủi ro theo thời gian để phân tích nhóm của bạn đang làm việc với các rủi ro dự án tốt như thế nào.
Create a new report. Bạn có thể tạo mới một report từ đầu.

Nếu bạn chỉnh sửa một report đã có hay tạo mới một report từ đầu, bạn có thể khai báo công khai nó trên Report Server để nó có thể được áp dụng sẵn sàng cho phần còn lại của nhóm bạn. Nếu bạn muốn chỉnh sửa một report đã có hay tạo mới một report, bạn có thể sử dụng một trong các cách sau:

Sử dụng Microsoft Office Excel® để tạo các pivot tables từ dữ liệu trong reporting databases.
Tạo mới một Report Server project trong Visual Studio và sau đó tạo mới các report hay import các report đã có. Tạo một Report Server project trong Visual Studio là phương pháp mạnh nhất và linh hoạt để tạo và chỉnh sửa các report.

Lưu ý: Có thể sử dụng Report Builder, hoạc từ các team reporting site; tuy nhiên công cụ này không hỗ trợ tốt cho các Visual Studio reporting scenarios và không được khuyến khích.

Thông tin bổ sung

Để có thêm thông tin về việc chỉnh sửa các report đã có, hãy xem "How To: Customize a Report with Visual Studio Team Foundation Server."
Để có thêm thông tin về việc tạo một custom report, hãy xem "How To: Create a Custom Report in Visual Studio Team Foundation Server."
Hướng dẫn từng bước để tạo một Risk over Time report, hãy xem "How To: Create a Risk over Time Report with Visual Studio Team Foundation Server."

Kiến trúc vật lý

Team Foundation Server được build trên SQL Server 2005 và sử dụng SQL Server Analysis Services để tổng hợp dữ liệu và điều khiển các report. Bạn có thể tạo mới các report bằng cách sử dụng Microsoft Excel hay Visual Studio 2005 Report Designer. Các report được lưu trữ trên SQL Server 2005 Reporting Services và có thể được xem từ report server Web site, team SharePoint project portal và từ Reports node trong Team Explorer. Hình 15.1 hiển thị kiến trúc vật lý của report.

Hình 15.1 Physical Reporting Architecture

Mỗi thành phần TFS duy trì tập các transaction databases cho riêng mình. Bao gồm có các work items, source control, tests, bugs, và Team Build. Dữ liệu này được tổng hợp vào một relational database. Sau đó dữ liệu này được đặt trong một Online Analytical Processing (OLAP) cube để hỗ trợ xu hướng report cơ bản và phân tích dữ liệu nâng cao .

TfsWarehouse relational database là một kho chứa dữ liệu được thiết kế để sử dụng cho việc tuy vấn dữ liệu hơn là các transaction. Dữ liệu được chuyển giao từ các TFS databases khác nhau, được tối ưu cho các transaction processing, vào trong kho dữ liệu này cho mục đích báo cáo. Kho này mục đích chính không dùng lưu trữ các báo cáo, nhưng bạn có thể sử dụng nó để build các report. TfsReportDS data source điểm đến relational database. The Team System Data Warehouse OLAP Cube là một OLAP database kết nối thông qua SQL Server Analysis Services. The cube có ích cho các report cung cấp dữ liệu phân tích các xu hướng như là 'có bao nhiêu lỗi được sữa chữa trong tháng này so với tháng vừa qua?' TfsOlapReportDS data source điểm đến Team System Data Warehouse OLAP cube trong các analysis services database.

Các thành phần của hệ thống Reporting

Reporting system bao gồm các thành phần của server-side và client-side sau:

Các thành phần Server-Side

Các thành phần Server-side gồm có:

Report server databases. Những databases này chứa các report definitions, historical reports, và configuration data(sự cấu hình dữ liệu).
Report server Web service. Web service này cung cấp các chương trình truy cập đến Report Server.
Report Manager Web site. Trang web này cho phép các user kết nối đến Report Server thông qua một Web browser.
Windows service. Service này cung cấp các lịch trình và phân phối các report snapshots.

Các thành phần Client-Side

Các thành phần của Client-side gồm có:

Browser. Thành phần này cung cấp truy cập đến Report Manager Web site.
Team Explorer. Thành phần này cung cấp truy cập đến các reports thông qua Visual Studio.

Các công cụ phát triển Report

Các tool phát triển gồm có:

Business Intelligence Designer Studio (BIDS). Thành phần này cho phép các lập trình viên thiết kế và triển khai các report từ Visual Studio 2005.
Excel. Excel có thể được sử dụng để khởi tạo các pivot tables từ reporting store.
Report Builder. Thành phần này cho phép các end users thiết kế các ad-hoc report. Nó không được hỗ trợ tốt cho Team Foundation reporting scenarios và không được khuyến khích.

Tổng kết

The MSF Agile và MSF CMMI process templates mỗi phần cung cấp một tập các reports mặc định cho các bugs, release management, testing, và work item tracking:

Bug-related reports trong process templates cho phép bạn nhìn thấy các kiểu lỗi(bugs) đang được tạo ra để giúp đỡ xác định các xu hướng lỗi.
Release management reports giúp bạn xem xét thử ứng dụng của bạn có phù hợp với các bản phát hành.
Testing reports cho phép bạn kiểm soát hiệu quả và tiến độ của các nỗ lực kiểm thử của bạn.
Work item reports cho phép bạn đánh giá tình trạng hiện thời của dự án và tiến độ dự án của bạn.

Nếu bạn muốn chỉnh sửa một report đã có và tạo mới một report, bạn có thể sử dụng Report Builder có trong trang team reporting site, sử dụng Excel để tạo các pivot tables từ dữ liệu trong reporting databases, hay tạo mới một Report Server project trong Visual Studio.

Tài nguyên bổ sung

Để có thêm thông tin về Team Foundation Server Reporting, hãy xem http://msdn2.microsoft.com/en-us/library/ms194922(VS.80).aspx

Chương 15 – Giải thích về Report

Nguyễn Thị Như Quỳnh — Tue, 08 Dec 2009 08:29:49 GMT

Revision 1 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/8/2009 4:29:49 PM

Chủ đề

Miêu tả kiến trúc Microsoft® Visual Studio® Team Foundation Server (TFS) reporting .
Xác định các thành phần tạo nên TFS reporting.
Miêu tả mục đích của từng report có sẵn.
Tìm hiểu process template nào chứa đựng report nào.
Tùy chỉnh và tạo mới các report.

Xem trước

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

Đọc phần "Scenarios and Solutions". Tìm hiểu những nguyên nhân thông thường để sử dụng TFS reporting và nghiên cứu mục đích của từng chuẩn report.
Đọc phần "Physical Architecture" . Nghiên cứu thành phần nào tạo nên reporting system và chúng tương tác với nhau như thế nào
Đọc phần "Customizing Reports" . Nghiên cứu cơ chế sẵn có cho sự tùy chỉnh và khởi tạo report.
Đọc chủ đề Làm thế nào kèm theo. Đọc các chủ đề Làm thế nào được đi kèm sau đây để để đi qua từng bước các thảo luận trong chương này.

o Làm thế nào - Tùy chỉnh một Report với Visual Studio 2005 Team Foundation Server"

o Làm thế nào - Tạo một Custom Report trong Visual Studio 2005 Team Foundation Server

o Làm thế nào - Tạo một Risk Over Time Report với Visual Studio 2005 Team Foundation Server

Tình huống và giải pháp

Sau đây là những câu hỏi phổ biến khi sử dụng TFS reports có thể trả lời được:

Khi nào ứng dụng của tôi sẵn sàng được vận chuyển?
Có phải tiến hành công việc theo kế hoạch?
Chất lượng của build là gì?
Tình trạng phát triển tùy vào việc xác định các tình huống, kịch bản định trước là gì?

• Làm thế nào hoàn thành công việc phát triển một cách nhanh chóng?

Có phải các lỗi cố định không?
Có phải là các bug đang được giảm bớt?

Team Foundation Server Reports

Bugs

Bugs by Priority. Là các correct bug sẽ được tìm thấy? Report này hiển thị cho bạn tỉ lệ của các high-priority bugs(lỗi có độ ưu tiên cao) được tìm thấy so với các low priority bugs(lỗi có độ ưu tiên thấp). Report này có sẵn trong cả hai quy trình mẫu được cung cấp.
Bug Rates. Làm cách nào mà các bug đang được tìm kiếm, sữa chữa và kết thúc nó một cách hiệu quả?Report này chỉ ra các xu hướng theo thời gian của các lỗi mới(new bug), bug backlogs(lỗi về truyền tải thông tin), và bug resolution(lỗi về độ phân giải màn hình). Report này có sẵn trong cả hai quy trình mẫu được cung cấp.

Release Management

Actual Quality versus Planned Velocity. Có bao nhiêu kịch bản được hoàn thành trước khi chất lượng không được chấp nhận? Report này trình bày các mối quan hệ của từng iteration, của kích cỡ ước lượng về chất lượng tổng thể. Report này có sẵn trong cả hai quy trình mẫu được cung cấp.
Builds. Quality of build là gì? Report này cung cấp một danh sách các build có sẵn bao gồm build quality và các thông tin chi tiết khác. Report này có sẵn trong MSF for CMMI Process Improvement.
Quality Indicators. Chất lượng phần mềm là gì? Report này tống kết các kết quả kiểm thử, các lỗi, code coverage và code churn vào một single report để theo dõi project health. Report này có sẵn trong MSF Agile và MSF CMMI.
Velocity. Làm thế nào nhóm có thể nhanh chóng hoàn thành công việc? Report này trình bày bằng cách nào mà nhóm có thể hoàn thành kế hoạch công việc và chỉ ra tỉ lệ thay đổi từ ngày này sang ngày khác. Report này có sẵn trong MSF Agile và MSF CMMI.
Scenario Details. Chúng ta thiết kế ứng dụng dựa trên kịch bản nào? Report này cung cấp thông tin trên mỗi kịch bản bao gồm completion status(tình trạng hoàn thành), risks(các rủi ro) và testing progress(tiến độ kiểm thử). Report này có sẵn trong MSF CMMI.

Testing

Kiểm thử reports cho phép bạn giám sát hiệu quả và tiến độ của các kiểm thử của bạn. Sau đây là các kiểm thử report(test report) có sẵn:

Regressions. Những kiểm thử nào đã qua được một mốc nhưng bây giờ lại thất bại?Report này trình bày một danh sách tất cả các kiểm thử đã thành công trước đó nhưng bây giờ thất bại. Report này có sẵn trong MSF CMMI.
Requirements Test History. Kiểm thử tốt như thế nào cho các kịch bản và các yêu cầu của tôi?Report này trình bày tiến độ kiểm thử dựa vào việc xác định các kịch bản và các yêu cầu. Report này có sẵn trongg MSF CMMI.
Test Failure Without Active Bug. Có phải có các lỗi để theo dõi các khuyết tật? Report này trình bày bất cứ kiểm thử nào đã thất bại và không được liên kết với một open bug. Report này có sẵn trong MSF CMMI.
Test Passing With Open Bug. Có phải danh sách lỗi(bug list) được cập nhật liên tục và nhất quán với chất lượng của ứng dụng? Report này trình bày các lỗi cũ mà các kiểm thử bây giờ đang được kiểm thử là vượt qua. Report này có sẵn trong MSF CMMI.
Load Test Tổng Kết. Kết quả của việc load các kiểm thử trên việc thi hành ứng dụng là gì?Report này trình các kết quả kiểm thử cho việc load các kiểm thử trên ứng dụng của bạn.Report này có sẵn trong MSF Agile.

Work Items

Work item reports cho phép bạn đánh giá tình trạng hiện tại của dự án và của tiến độ hiện tại của dự án của bạn. Sau đây là các work item reports có sẵn:

Open Issues and Blocked Work Items Trend. Còn bao nhiêu open issues? Report này trình bày các open issues còn tồn tại cũng như là xu hướng để giải quyết chúng. Report này có sẵn trong MSF CMMI.
Reactivations. Có bao nhiêu work items đang được tái kích hoạt? Report này trình bày các work items đã được giải quyết hay kết thúc sớm. Report này có sẵn trong MSF Agile and MSF CMMI.
Related Work Items. Các work item này phụ thuộc vào các work items khác là gì? Report này trình bày một danh sách các work item liên kết với các work item khác để bạn theo dõi các sự phụ thuộc(dependency). Report này có sẵn trong MSF CMMI.
Remaining Work. Có bao nhiêu công việc vẫn còn đang làm và khi nào kết thúc công việc ấy?Report này trình bày các công việc còn lại , được giải quyết và kết thúc theo thời gian. Lên kế hoạch trước các công việc còn lại cho phép bạn dự đoán thời điểm mà bạn sẽ hoàn thành code của bạn. Report này có sẵn trong MSF Agile và MSF CMMI.
Triage. Các work item nào cần được chọn để thực hiện theo kế hoạch(triage)? Report này trình bày tất cả các work item vẫn đang ở trong tình trạng đề xuất. Report này có sẵn trong MSF CMMI.
Unplanned Work. Có bao nhiêu công việc không được dự tính trước? Report này lập biểu đồ tổng các công việc so với các công việc còn lại và phân biệt các công việc có kế hoạch từ các công việc không có kế hoạch. Report này có sẵn trong MSF Agile và MSF CMMI.
Work Items. Các active work items là gì? Report này liệt kê tất cả các active work item. Report này có sẵn trong MSF CMMI.
Work Items by Owner. Có bao nhiêu công việc được phân chia cho từng thành viên của nhóm? Report này trình bày các work item trên mỗi thành viên của nhóm. Report này có sẵn trong MSF CMMI.
Work Items by State. Có bao nhiêu active, resolved và closed work items ở đây? Report này liệt kê các work items được tổ chức bởi các state. Report này có sẵn trong MSF CMMI.

Tùy chỉnh các Report

Bạn có thể cần một report mà không có trong các MSF process templates. Thì bạn có thể tùy chỉnh các reports bằng một trong ba cách sau đây:

Use a filter on an existing report. Rất nhiều report cung cấp các tham số mà bạn có thể sử dụng để lọc các report. Thí dụ date, area, iteration, và các priority filters(lọc ưu tiên) có sẵn. Sử dụng những filter(bộ lọc) này để xem lại một tập hợp các data được cung cấp trong report. Hãy lưu ý là những filter này chỉ có tính chất tạm thời và sẽ bị mất đi khi bạn không duyệt các report nữa.
Customize an existing report. Nếu một report bạn muốn tương tự như một report đã có, thường thì dễ nhất là copy report đã có và sau đó chỉnh sửa nó. Thí dụ, bạn có thể muốn phân chia các rủi ro theo thời gian để phân tích nhóm của bạn đang làm việc với các rủi ro dự án tốt như thế nào.
Create a new report. Bạn có thể tạo mới một report từ đầu.

Sử dụng Microsoft Office Excel® để tạo các pivot tables từ dữ liệu trong reporting databases.
Tạo mới một Report Server project trong Visual Studio và sau đó tạo mới các report hay import các report đã có. Tạo một Report Server project trong Visual Studio là phương pháp mạnh nhất và linh hoạt để tạo và chỉnh sửa các report.

Thông tin bổ sung

Để có thêm thông tin về việc chỉnh sửa các report đã có, hãy xem "How To: Customize a Report with Visual Studio Team Foundation Server."
Để có thêm thông tin về việc tạo một custom report, hãy xem "How To: Create a Custom Report in Visual Studio Team Foundation Server."
Hướng dẫn từng bước để tạo một Risk over Time report, hãy xem "How To: Create a Risk over Time Report with Visual Studio Team Foundation Server."

Kiến trúc vật lý

Hình 15.1 Physical Reporting Architecture

Các thành phần của hệ thống Reporting

Reporting system bao gồm các thành phần của server-side và client-side sau:

Các thành phần Server-Side

Các thành phần Server-side gồm có:

Report server databases. Những databases này chứa các report definitions, historical reports, và configuration data(sự cấu hình dữ liệu).
Report server Web service. Web service này cung cấp các chương trình truy cập đến Report Server.
Report Manager Web site. Trang web này cho phép các user kết nối đến Report Server thông qua một Web browser.
Windows service. Service này cung cấp các lịch trình và phân phối các report snapshots.

Các thành phần Client-Side

Các thành phần của Client-side gồm có:

Browser. Thành phần này cung cấp truy cập đến Report Manager Web site.
Team Explorer. Thành phần này cung cấp truy cập đến các reports thông qua Visual Studio.

Các công cụ phát triển Report

Các tool phát triển gồm có:

Business Intelligence Designer Studio (BIDS). Thành phần này cho phép các lập trình viên thiết kế và triển khai các report từ Visual Studio 2005.
Excel. Excel có thể được sử dụng để khởi tạo các pivot tables từ reporting store.
Report Builder. Thành phần này cho phép các end users thiết kế các ad-hoc report. Nó không được hỗ trợ tốt cho Team Foundation reporting scenarios và không được khuyến khích.

Tổng kết

The MSF Agile và MSF CMMI process templates mỗi phần cung cấp một tập các reports mặc định cho các bugs, release management, testing, và work item tracking:

Bug-related reports trong process templates cho phép bạn nhìn thấy các kiểu lỗi(bugs) đang được tạo ra để giúp đỡ xác định các xu hướng lỗi.
Release management reports giúp bạn xem xét thử ứng dụng của bạn có phù hợp với các bản phát hành.
Testing reports cho phép bạn kiểm soát hiệu quả và tiến độ của các nỗ lực kiểm thử của bạn.
Work item reports cho phép bạn đánh giá tình trạng hiện thời của dự án và tiến độ dự án của bạn.

Nếu bạn muốn chỉnh sửa một report đã có và tạo mới một report, bạn có thể sử dụng Report

Builder có trong trang team reporting site, sử dụng Excel để tạo các pivot tables từ dữ liệu trong reporting databases, hay tạo mới một Report Server project trong Visual Studio.

Tài nguyên bổ sung

Để có thêm thông tin về Team Foundation Server Reporting, hãy xem http://msdn2.microsoft.com/en-us/library/ms194922(VS.80).aspx

Chương 14 - MSF cho các Agile Software Development Projects

Nguyễn Thị Như Quỳnh — Tue, 08 Dec 2009 08:21:39 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 12/8/2009 4:21:39 PM

Chủ đề

Tìm hiểu khi sử dụng Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) process template.
Xác định các nhóm điển hình sử dụng the MSF Agile process template như thế nào.
Tùy chỉnh MSF Agile process template để đáp ứng các nhu cầu cụ thể của nhóm bạn.

Xem trước

Các process được xác định bởi MSF Agile process template kết hợp các ý tưởng chủ chốt từ Agile software movement, cùng với các nguyên tắc và bài tập thực hành từ MSF. Các process hỗ trợ một chiến thuật agile software engineering mà sử dụng các multiple iterations và một scenario-based approach cho việc build các ứng dụng. Template cung cấp tự động hóa và các hướng dẫn cần thiết để hỗ trợ team development của bạn, bao gồm cả configuration management, project management, work item tracking, và một project portal cho sự giao tiếp.

Chương này giải thích về workflow của một MSF Agile software development project điển hình, trình bày các thí dụ của các team đang sử dụng MSF Agile process, và mô tả các template setting mặc định và những tùy chọn để bạn tùy chỉnh các template được cung cấp.

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

Đọc chương này nếu bạn muốn đạt được sự hiểu biết tốt hơn về cách làm việc của MSF Agile process template và process guidance works cũng như là bằng cách nào nó được sử dụng thành công bởi các team khác nhau. Để đạt được lợi ích tốt nhất từ chương này, bạn nên:

Đọc phần "MSF for Agile Software Development Defaults". Để tìm hiểu chi tiết của MSF Agile process template bao gồm các reports, work items, và permissions mặc định.
Đọc qua phần "Ví dụ MSF for Agile Software Development trong thực tế". Để xem bằng cách nào các nhóm có trong đời thật đã thành công khi sử dụng MSF Agile để phát triển và phát hành các ứng dụng.
Đọc phần "Chương 13, Giải thích về Process Template." Nếu bạn muốn tìm hiểu nhiều hơn về các proccess templates nói chung, hãy đọc "Chương 13 - Giải thích về Process Template"

Workflow cho MSF for Agile Software Development

The MSF Agile process template xác định một tập các task được thực thi trong suốt các iteration bởi các role khác nhau bao gồm một software-development lifecycle có các business analysts, architects, project managers, developers,và các testers. Hình 14.1 hiển thị các hoạt động chính liên quan đến mỗi task được xác định.

Hình 14.1 MSF Agile Tasks and Key Activities

MSF for Agile Software Development Defaults

Khi bạn tạo mới một team project bằng cách sử dụng MSF Agile process template, một trang phác thảo khái niệm hướng dẫn quy trình(process guidance) được hiển thị trong cửa số chính của Microsoft Visual Studio®. Đây là quan điểm ban đầu của bạn về MSF Agile process. Bạn cũng có thể truy cập thông tin này từ project portal home page.

Cấu hình của các tool cũng đi ra khỏi sự mô tả của các process và bao gồm các work items (như là các scenarios, quality of service requirements, tasks, bugs, và các risks), project reports, roles (groups và permissions), và một project portal. Các item chính được cung cấp bởi MSF Agile template gồm có:

Work items
Groups and permissions
Source control
Areas and iterations
Reports
Portal

Các phần chi tiết sau là các phần quan trọng mặc định sẵn sàng cho bạn khi sử sụng MSF Agile process template.

Work Items

The MSF Agile process template chứa các work item type sau:

• Bug. Đại diện một problem hay potential problem trong ứng dụng của bạn.

• Risk. Đại diện một possible event hay condition mà có một tác động tiêu cực trên project của bạn.

• Scenario. Đại diện cho một single path của user interaction qua system mà bạn đang build.

• Task. Xác định một item cụ thể của công việc cho một team member để thực hiện.

• Quality of Service Requirement. Đại diện cho một yêu cầu phi chức năng(non-functional requirement) như là một security, performance hay manageability requirement.

Khi bạn tạo mới một team project dựa trên MSF Agile process template, các work item sau sẽ được tạo cho bạn. Điều này giúp bạn làm việc bằng cách cung cấp một tập các task thông thường mà bạn cần thực hiện trên project initiation.

• Set up: Set Permissions. Mục đích của task này là để add các team members thành một trong 4 nhóm bảo mật(security group): Build Services, Project Administrators, Contributors, hay Readers.

• Set up: Migration of Source Code. Mục đích của task này là để di chuyển source code hiện tại của bạn từ Microsoft Visual SourceSafe®, nếu bạn đang di chuyển một project đã có đến Microsoft Visual Studio Team Foundation Server (TFS). Bạn nên hoàn thành việc di chuyển của source code trước khi bạn cho phép các team members truy cập đến team project.

• Set up: Migration of Work Items. Nếu bạn đang mang một project đã có vào TFS, bạn có thể di chuyển các work items như là các bugs và các tasks từ Clearquest hay một comma-separated value (CSV) file. Bạn nên hoàn thành sự di chuyển này của các work item trước khi bạn cho phép các team members truy cập vào team project.

Set up: Set Check-in Policies. Mục đích của task này là để setup các business rule hay policies mà bao quanh các source code check-ins.
Set up: Configure Build. Mục đích của task này là để tạo một source tree ban đầu và cài đặt build để chạy trên một khoảng thời gian cơ bản (thường là daily) .
Set up: Send Mail to Users for Installation and Getting Started. Mục đích của task này là để gửi một e-mail đến các team member để cung cấp thông tin về những TFS mà chúng nên kết nối đến hoặc team project mà chúng nên sử dụng để bắt đầu làm việc trên team project.

• Create Vision Statement. Mục đích của task này là để tạo một vision statement cho project - một view của kết quả mong muốn cuối cùng của project của bạn, được share bởi tất cả các project stakeholders(những người liên quan đến project).

• Set up: Create Project Description on Team Project Portal. Mục đích của task này là để thay đổi sự mô tả của project mặc định để mô tả các team project mới tốt hơn, thí dụ mô tả mục đích của project, các mục tiêu, hay tầm nhìn.

Create Personas. Mục đích của task này là để tạo các personas đại diện cho các user tương tác với hệ thống. Bạn có thể sử dụng các personas khi suy nghĩ qua về thiết kế ứng dụng như họ là những user nhắm mục tiêu cho hệ thống.
Define Iteration Length. Mục đích của task này là để xác định các chu kỳ lặp iteration cycle được sử dụng bởi project. Điều này dựa trên kích cỡ và mức độ phức tạp của project.

• Create Test Approach Worksheet including Test Thresholds. Mục đích của task này là để hiểu chiến thuật kiểm thử của bạn(test strategy) từ lúc bắt đầu của project iteration. Tìm hiểu phương pháp kiểm thử có thể giúp bạn lên lịch trình trước các nhiệm vụ kiểm thử(testing tasks) của bạn hiệu quả hơn và sẽ cho phép các lập trình viên của bạn thực thi và nhớ các lời khuyên về kiểm thử.

Brainstorm and Prioritize Scenarios List. Mục đích của task này là để xác định và ưu tiên các tình huống có lợi quan trọng.
Brainstorm and Prioritize Quality of Service Requirements List. Mục đích của task này là để xác định các yêu cầu QoS phi chức năng như là security(bảo mật), performance(thực thi) và manageability scenarios(quản lý các kịch bản).
Set up: Create Project Structure. Mục đích của task này là để tạo cấu trúc project mà nắm bắt các area mà nhóm phát triển sẽ làm việc trên đó.
Create Iteration Plan. Mục đích của task này là để xác định bằng cách nào để phân chia các development efforts lặp đi lặp lại.

Reports

Các report sau mặc định là có sẵn với MSF Agile process template:

• Bugs by Priority. Là những lỗi(bug) chính xác được tìm thấy? Report này hiển thị cho bạn các lỗi có tỉ lệ ưu tiên cao so với tỉ lệ ưu tiên thấp được tìm thấy.

• Bug Rates. Làm thế nào để các lỗi được tìm thấy, sữa chữa và khóa lại một cách hiệu quả? Chart(biểu đồ) này sẽ hiển thị các xu hướng theo thời gian của các bug mới, bug backlogs, và bug resolution.

• Builds. Chất lượng của một build là gì? Report này cung cấp một danh sách các build có sẵn gồm có build quality và các thông tin chi tiết khác.

• Project Velocity. Làm thế nào team có thể hoàn thành nhanh chóng công việc của mình? Report này hiển thị bằng cách nào team có thể nhanh chóng hoàn thành kế hoạch công việc và hiển thị tỉ lệ thay đổi hàng ngày.

• Quality Indicators. Chất lượng của phần mềm là gì? Report này tập hợp các test results, bugs, code coverage, và code vào một single report để theo dõi tình trạng chất lượng của dự án.

• Load Test Tổng Kết. Report này trình bày các kết quả kiểm thử(test result) đối với việc load các kiểm thử(testing) trên ứng dụng của bạn.

• Regressions. Report này trình bày một danh sách tất cả các kiểm thử mà trước đây đã được thông qua nhưng bây giờ thì không.

• Reactivations. Có bao nhiêu work items đang được tái kích hoạt? Report này hiển thị các work item đã được giải quyết hay bị đóng lại sớm.

• Related Work Items. Các work item này phụ thuộc vào các work item khác là gì? Report này trình bày một danh sách các work item mà được liên kết đến các work item khác vì thế bạn có thể theo dõi các phụ thuộc.

Remaining Work. Bao nhiêu công việc còn phải thực hiện và khi nào nó sẽ hoàn thành? Report này trình bày số lượng công việc còn lại cần được giải quyết và kết thúc đúng hạn. Quy hoạch các công việc còn lại cần được giải quyết ở phía trước có thể cho phép bạn đoán điểm nào mà tại đó bạn sẽ hoàn thành code.
Unplanned Work. Có bao nhiêu công việc không được dự tính trước?Report chart tổng kết các công việc so với phần công việc còn lại và phân biệt các kế hoạch từ các hoạt động không có kế hoạch.
Triage. Các work item nào cần được ưu tiên sữa chữa? Report này trình bày tất cả các work item vẫn còn đang trong tình trạng đề nghị.

• Work Items. Các active work items là gì? Report này lên danh sách tất cả các work item đang hoạt động.

Work Items by Owner. Có bao nhiêu công việc được phân chia cho mỗi thành viên của nhóm? Report này trình bày số lượng work items trên mỗi team member.
Work Items by State. Có bao nhiêu công việc, và những hạng mục công việc nào đã giải quyết và đã ngưng ở đó? Report này trình bày danh sách tất cả các active, resolved, và closed work item.

Groups và Permissions

Các group sau mặc định có sẵn trong MSF Agile process template:

Readers. Các thành viên của group này chỉ có quyền read-only truy cập đến team project.

• Contributors. Các thành viên của group này có thể thêm, chỉnh sửa, và xóa các item có trong team project.

• Build Services. Các thành viên của group này có quyền build service permissions cho team project. Group này thường chỉ sử dụng cho các service accounts.

Project Administrators. Các thành viên của group này có thể thực hiện tất cả các hoạt động trong team project.

Source Control

MSF Agile sử dụng các source control settings sau:

Multiple Checkout. Mặc định MSF Agile cho phép nhiều checkouts để cho phép nhiều team member làm việc trên cùng một file tại cùng một thời điểm. Bất cứ kết quả những cuộc xung đột nào cũng phải được giải quyết tại thời điểm check-in.

• Permissions. Các permission mặc định trên source control bao gồm:

o Project Administrators. Có tất cả các quyền.

o Build Services. Có quyền read, pend changes, check-in, label, start build, và edit build.

o Contributors. Có quyền read, pend changes, check-in, check-out, label, và start build.

o Readers. Chỉ có quyền read-only khi truy cập đến source control.

Areas and Iterations

MSF Agile process template không cung cấp một sự phân loại cấu trúc cho cả các areas hay các iterations. Phương pháp đề nghị là phân ra các area dựa trên các thành phần hay các chức năng của project. Các iteration có thể có chu kì thời gian cơ bản mà bạn sẽ lặp lại một tập hợp cụ thể của các hoạt động chính như là plan, develop, và test.

Thí dụ về bài tập MSF for Agile Software Development

Các ví dụ sau đây trình bày cho bạn bằng cách nào mà MSF for Agile Software Development process được áp dụng và được sử dụng bởi patterns & practices team với Microsoft cũng như là bởi các development team không thuộc Microsoft.

Thí dụ 1: patterns & practices Teams

Thí dụ sau đây trình bày một patterns & practices project điển hình được thực thi bằng cách sử dụng MSF Agile process.

New Project Through Iteration 0

Người quản lý sản phẩm:

1. Tương tác với các khách hàng và các người liên quan đến project(stake holders) để thu thập các yêu cầu của dự án. Những thông tin này được lưu giữ trong một Microsoft Office Word document có tên là Project Back Log.

2. Tạo một khái quát về tầm nhìn cho project bằng cách sử dụng Microsoft Office PowerPoint®.

3. Cùng thu thập ý tưởng với khách hàng và các stakeholders và xác định các trường hợp có nêu rõ các yêu cầu và tầm nhìn của dự án.

4. Làm việc với project manager và các stakeholders khác để xét ưu tiên các tình huống, kịch bản(scenarios).

Quản lý dự án:

1. Nắm chắc các trường hợp như là các work item ở trong TFS.

2. Xác định iteration cycle duration, tùy thuộc vào kích cỡ dự án, và khả năng phân phối.

Pre-Iteration Planning

Project manager quyết định kịch bản nào nên được làm việc trong các iterations, tùy theo độ ưu tiên của chúng.
Product manager cùng với project manager tạo các Quality of Service (QoS) Requirements cho các kịch bản. Sau đó các QoS sẽ liên kết với các kịch bản, tình huống đó.

Iteration Planning

Project manager:

1. Chia các kịch bản ra thành các development tasks, hợp tác với các developers và các team member khác.

2. Nắm chắc các development tasks trong TFS và liên kết chúng với các kịch bản.

3. Định hình tiêu chuẩn nghiệm thu cho từng công việc phát triển.

4. Chia các QoS requirements thành các test tasks.

5. Nắm chắc các test tasks trong TFS và liên kết chúng với các QoS

6. Định hình tiêu chuẩn nghiệm thu cho từng test tasks.

7. Lên kế hoạch và phân chia công việc.

Nhà lập trình ước tính từng development task.

Quan trọng- Nếu giống như các tasks (developer stories) có thể mất lâu hơn 1 hay hai ngày để thực thi, sau đó bạn nên chia nhỏ thành các sub-stories.

Các nhà kiểm thử tester, cung cấp các sự đánh giá ước tính cho mỗi công việc kiểm thử(test tasks).

During the Iteration

Project manager hướng dẫn các iteration.
Các lập trình viên, viết code cho các development task, và sau đó kết thúc các tasks mỗi khi các tiêu chuẩn nghiệm thu được đáp ứng đầy đủ.
Các nhà kiểm thử thực thi các test tasks mà anh ta hay cô ta được phân công và sau đó tạo ra các lỗi mới(các work items) cho bất kỳ vấn đề nào được xác định.

After the Iteration

Nhà quản lý dự án project manager:

1. Đánh giá tiến độ dự án và mức độ ưu tiên của bất kì kịch bản nào chưa hoàn thành trong các iteration hiện có.

2. Cung cấp một status report cho các stakeholders.

3. Quyết định xem kịch bản nào nên được thực hiện trong iteration kế tiếp dựa trên mức độ ưu tiên của nó.

Nhà quản lý dự án product manager:

1. Bổ sung thêm bất kỳ kịch bản mới được tìm ra.

2. Phân chia mức độ ưu tiên của kịch bản(ở chỗ nào cần thiết).

3. Cùng với các project manager, tạo các QoS requirements cho project. QoS được liên kết với các kịch bản.

Thí dụ 2: Field Customer Engagement

Thí dụ sau trình bày bằng cách nào mà MSF Agile process được sử dụng bởi một field customer engagement.

New Project Through Iteration 0

Các nhà phân tích kinh tế(business analyst):

1. Tạo một (một-trang) vision statement ngắn.

2. Xác định một on-site customer là người cung cấp đầu vào(input) và tạo ra personas cho hệ thống.

3. Thu thập các kịch bản (chỉ tên) với khách hàng.

4. Xác định cơ cấu ưu tiên các kịch bản với khách hàng.

5. Viết các kịch bản cho các tình huống sắp đến.

Nhà quản lý dự án:

1. Tập hợp các nhà phát triển lại với nhau và thu các dự tính, ước tính của họ. Các dự đoán, ước tính sẽ được gắn lại theo thứ tự của độ lớn ước tính.

2. Kiểm tra nếu độ ưu tiên thay đổi như là kết quả của các chi phí.

3. Lên kế hoạch của kịch bản cho các vòng lặp sắp đến.

Các kiến trúc sư phân chia các kịch bản ra thành các công việc kiến trúc.
Lập trình viên:

1. Phân chia các kịch bản thành các tác vụ phát triển.

2. Xác định chiến lược thiết kế phù hợp (Continuous Integration nếu có thể).

Các nhà kiểm thử phân chia các kịch bản thành các tác vụ kiểm thử.

During the Iteration

Nhà quản lý dự án project manager:

1. Hướng dẫn các vòng lặp(iteration).

2. Hướng dẫn dự án(project).

Nhà kiến trúc xác định kiến trúc solution.
Lập trình viên, thực thi một tác vụ phát triển.
Nhà kiểm thử, kiểm thử một tình huống.

Sau Iteration 0

Các tác vụ thay đổi một chút ở điểm này .

Nhà phân tích kinh tế:

1. Update các personas (ở nơi nào cần thiết).

2. Thêm vào bất kì tình huống nào mới được khám phá.

3. Xác định lại cơ cấu độ ưu tiên của các kịch bản (ở nơi nào cần thiết).

4. Viết các kịch bản cho các vòng lặp sắp tới.

Nhà quản lý dự án project manager:

1. Ước tính bất cứ trường hợp mới nào sẽ xảy đến.

2. Lên kế hoạch kịch bản cho các upcoming iteration.

Nhà kiến trúc phân chia kịch bản thành các tác vụ kiến trúc(architecture tasks).
Các lập trình viên:

1. Phân chia kịch bản thành các tác vụ phát triển(development tasks).

2. Update các build process (Continuous Integration nếu có thể).

Các Tester phân chia các kịch bản thành các tác vụ kiểm thử(test tasks).

Tùy chỉnh MSF Agile Process Template

Bạn có thể sử dụng hai phương thức để tùy chỉnh MSF Agile process template cho phù hợp với các yêu cầu tổ chức cụ thể của bạn:

Manually customize the XML files. Tùy chỉnh bằng tay rất dễ bị lỗi nhưng vẫn cho phép bạn dễ dàng điều khiển dựa trên việc tùy chỉnh các quy trình mẫu(process template). Để có thêm thông tin, hãy xem "Customizing Process Templates" tại http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx ,
Process Template Editor. Phiên bản mới nhất của Visual Studio 2005 Team Foundation Server Power Tool - một tập các enhancements, tools, và command-line utilities cải thiện TFS experience - cung cấp cho bạn một user interface-based tool, mà bạn có thể sử dụng để có một cái nhìn tổng quát và tùy chỉnh các process templates. Khi kết nối đến TFS, bạn có thể sử dụng tool này để tùy chỉnh các work item type definitions và global lists trên một active project. Để có thêm thông tin, hãy xem "How To: Customize a Process Template in Visual Studio Team Foundation Server."

Tổng kết

The MSF Agile process template xác định một tập các tác vụ được thi hành bởi các role khác nhau liên quan đến một software-development lifecycle. The MSF Agile process template định nghĩa các work items, groups và permissions, source control, areas and iterations, reports và một team portal để hỗ trợ các agile process.

Nếu process template mặc định không đáp ứng được yêu cầu quy trình của bạn(process requirements), bạn có thể tùy chỉnh template bằng cách tùy chỉnh bằng tay XML process definition files hay bằng cách sử dụng Process Editor Tool mà liên kết với TFS Power Tools.

Tài nguyên bổ sung

Để download the MSF Agile process template, hãy đến http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F-48FB-824E-828BF593C34D&displaylang=en
Để download the Team Foundation Server Power Tool bao gồm Process Template Editor, hãy đến http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx
Để có thêm thông tin về process template customization, hãy xem "Process Template Customization Overview" tại http://msdn2.microsoft.com/en-us/library/ms194945(VS.80).aspx
Để có thêm thông tin về bằng cách nào để tùy chỉnh bằng tay(manually customize) process templates, hãy xem "Customizing Process Templates" tại http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx

Chương 13 – Giải thích về Process Templates

Nguyễn Thị Như Quỳnh — Wed, 25 Nov 2009 13:53:09 GMT

Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 11/25/2009 9:53:09 PM

Chương 13 – Giải thích về Process Templates

Filed under: TFS

Chủ đề

Tìm hiểu mục đích, nội dung và cấu trúc của các quy trình mẫu process templates.
Học về
Nghiên cứu sự khác nhau chính giữa hai quy trình mẫu Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) và MSF for CMMI® Process Improvements (MSF CMMI) process templates.
Tùy chỉnh các process template để đáp ứng nhu cầu cụ thể của team của nhóm bạn.

Xem trước

Chương này giải thích vai trò của các process template trong Microsoft Visual Studio® 2005 Team Foundation Server (TFS). Nó xác định các chức năng chính và sự khác nhau chính giữa hai process templates được cung cấp: MSF Agile và MSF CMMI.

Các quy trình phát triển phần mềm(software-development processes) thì mềm thường phức tạp, liên quan đến nhiều mức độ của các hoạt động phụ thuộc lẫn nhau. Những quy trình này nói chung là có sẵn cho các nhóm phát triển trong các dạng tài liệu nhưng thường không được có các tool để thực hiện. Việc không hỗ trợ của các tool này gây khó khăn cho các nhóm phát triểm triển để tìm hiểu và làm theo các quy trình một cách nhất quán. Các project manager có thể sử dụng nhiều tool khác nhau cho việc quản lý project, requirement management(quản quản lý các yêu cầu)cầu, bug tracking(theo dõi các lỗi), hay review management và nhưng chúng thường không được tích hợp tốt. Thiếu sự thống nhất này gây khó khăn hơn trong việc thực thi một phương pháp phù hợp giữa các project và để à tạo ra các report thích hợp để thúc đẩy hiểu biết đồng bộ trong toàn đội nhóm về tiến độ và tình hình dự án. Thiếu sự nhất quán này có thể dẫn đến việc kết quả làm cho à quá trình phân tích thiếu độ tin cậy, sẽ làm khó khăn hơn trong việc xác định và thực thi việc cải tiến nâng cấp các quy trình theo thời gian.

Visual Studio Team System (VSTS) và TFS cung cấp một môi trường tích hợp để hỗ trợ hầu hết các quy trình hoạt động có liên quan đến một dự án phát triển phần mềm. TFS thực thi phướng cơ chế pháp át triển vòng đời(life-cycle methodologies) của nó đời phần mềm qua cách sử dụng các process templates. Một process template là một tập các file ác tập tin Extensible Markup Language (XML) cung cấp các chi tiết kĩ thuật cho các process quy trình và các artifact phần tạo nên một cơ chế phương pháp phát triển(development methodology)triển phần mềm. Chương này giải thích kiến trúc của một quy trình mẫu(process process template ) và các thành phần của nó để bạn hiểu hơn về cách thức làm sao để sử dụng và tùy chỉnh các process template được cung cấp.

Nếu các process template đã có không phù hợp với quy trình phát triển của nhóm của bạn, thì bạn có thể tạo một process template mới, chỉnh sửa các template có sẵn, hoặc chọn từ các process templates được cung cấp bởi Microsoft Partners. Để xem các process templates được cung cấp bởi Microsoft Partners, hãy xem: http://msdn2.microsoft.com/en-us/teamsystem/aa718801

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

Sử dụng chương này để tìm hiểu kiến trúc process template , cấu trúc, và sự tùy biến(customization). chỉnh các quy trình đó. Để có được lợi ích tốt nhất từ chương này, bạn nên:

Đọc phần "MSF Agile and MSF CMMI Process Templates". Để tìm hiểu về các process template mặc định và bằng cách nào để chọn template mà phù hợp nhất với nhu các yêu cầu của nhóm bạn.
Đọc phần "Customizing Process Guidance". Để tìm hiểu cách thức tùy chỉnh các process template đã có để phù hợp với nhu cầu của nhóm bạn hơn.

MSF Agile and và MSF CMMI Process Templates

Team Foundation Server đi kèm với hai process template: MSF Agile and và MSF CMMI. Hai process templates này hướng vào hai phong cách khác nhau của việc phát triển phần mềm. Bạn nên sử dụng MSF Agile nếu bạn đang triển khai một phương pháp nhanh(agile methodology) để thiết kế phần mềm của bạn. nhanh chóng. MSF Agile khuyến khích kiểm thử test-driven development và các thực hành agile nhanh nhẹn khác. Bạn nên sử dụng MSF CMMI nếu bạn đang theo đuổi phương pháp Software Engineering Institute (SEI) Capability Maturity Model® Integration. Đây là một quy trình chính thức(formal process) thức nhằm cải thiện các quy trình phát triển đã có.

Các template khác nhau trong những gì mà chúng được cung cấp. Thí dụ, chúng tạo ra các loại report mặc định và các loại work item khác nhau. Những template có thể dễ dàng được chỉnh sửa cho phù hợp với các nhu cầu của project của bạn.

Customizing Process Guidance

Hướng dẫn tùy chỉnh các Quy trình

Project mà bạn đang tạo có thể không phù hợp với các process template được cung cấp với VSTS. Bạn có thể cần một loại work item khác hay bạn đang sử dụng một process methodology phương pháp quy trình hoàn toàn khác. Thí dụ, nếu bạn đang sử dụng SCRUM không đề cập đến các sprint trong các process template hiện có. Trong trường hợp này bạn cần sửa đổi hoặc thay thế các process template đã có cho phù hợp với phương pháp luận(methodology) luận mà nhóm bạn sử dụng.

Kiến trúc Process Template Architecture

Có ba phần quan trọng trong kiến trúc của process template:

• Process template plug-ins

• XML process definition files

• New Team Project Wizard

Process Template Plug-ins

Các process template plug-in là các thành phần mà run chạy khi một team project mới được tạo. Một plug-in thiết lập các tập tin file cần thiết và cấu hình data dữ liệu cho một khu vực cụ thể(specific area ) cụ thể của template. Các plug-in sau thì available out-of-box với có sẵn trong TFS.

Classification - Xác định một team project's initial iteration và areas(ccác vùng iteration và các khởi tạo area ban đầu của dự án nhóm). team project.

Groups and Permissions - Xác định một team project's initial các security groups group và các permission ban đầu của chúng. teamp project.

Windows SharePoint Services - Xác định project portal cho team dựa trên một trang Microsoft Windows SharePoint® site template. Nó cũng định nghĩa các template file và process guidance. hướng dẫn quy trình.

Work Item Tracking - Xác định một team project's initial các loại work itemtypes, queriesquery, và work item instancesinstance ban đầu của team project.

Reports - Xác định một team project's initial reports các report và thiết lập các trang report site. ban đầu của dự án nhóm.

Version Control -Xác định một team project's initial các version control security permissionspermission, và các check-in notes. note ban đầu của dự án nhóm.

Bạn có thể chỉnh sửa mỗi từng tập tin định nghĩa các plug-in definition file để tùy chỉnh một process template. Ngoại trừ các classification plug-in, bạn cũng có thể delete xóa các tập tin định nghĩa các plug-in definition files để tùy chỉnh một process template.

Các tập tin XML Process Definition Files

The xác định các quy trình

Các tập tin XML process definition files xác định các quy trình là một tập các tập tin XML xác định một tập các task(nhiệm vụ) mà task cần được run chạy để cấu hình chính xác một team project mới cho process. Khi bạn sử dụng New Team Project Wizard để tạo một team project, nó chạy yêu cầu các plug-in. Mỗi plug-in đọc các ác tập tin XML process definition file xác định các quy trình tương ứng của nó để thu được danh sách các task mà nó phải runchạy. Bằng cách sử dụng các các tập tin XML process definition files, xác định các quy trình, bạn xác định rõ các cấu hình và cài đặt gì mà các plug-in phải thực thi. Sau đây là các chi tiết về các tập tin XMLfile:

Work Item Tracking XML - Process definition file Tập tin xác định quy trình này có tên là Workitems.xml và được đặt trong thư mục Work Item Trackingfolder trong hệ phân cấp thư mục process templatefolder hierarchy. Có ba loại quan trọng của các task cần chỉ rõ: work item types, work item queries, và work item instances.

o Work Item Types - Xác định các rules, fields, states, và transitions cho một phần của công việc mà sẽ được theo dõi trên một team project như là các task, bug,vbug, và các requirements.

o Work Item Queries - Được sử dụng để tìm kiếm các group cụ thể của các work item, như là các task hay các active bug. Các work item query được xác định trong các tập tin work item query (WIQ) files trong thư mục Queriesfolder bên dưới thư mục Work Item Tracking folder trong hệ phân cấp các thư mục process templatefolder hierarchy.

o Work Item Instances - Tập ban đầu các work item instances được tạo mặc định khi bạn tạo team project.

Classification XML - Process definition file Tập tin xác định quy trình này có tên là Classification.xml và được đặt trong thư mục Classification folder trong hệ phân cấp các thư mục process templatefolder hierarchy. Nó bao gồm có hai phần: Iterations và Areas.

o Iterations - Được sử dụng để xác định số lần mà team sẽ repeat một tập đặc biệt các major activities hoạt động chính (như là plan, develop, test). Iterations ảnh hưởng đến work item query và report bởi vì iterations được sử dụng để nhóm các work items.

o Areas - Được sử dụng để tổ chức công việc trong team project. Thí dụ, một team có thể tổ chức công việc dựa trên sản phẩm hay chức năng, như là UI area, Application area, và Database area. Areas được sử dụng để nhóm các work items cho các query và các report.

Windows SharePoint Services XML - Process definition file Tập tin định nghĩa quy trình có tên là WssTasks.xml và được đặt trong thư mục Windows SharePoint Servicesfolder trong hệ phân cấp các thư mục process templatefolder hierarchy. Có ba task quan trọng để xác định rõ: Site Template (site template nào để sử dụng), Document Libraries (document libraries nào để tạo), và Folders and và Files ( folders and và files nào để copy vào document libraries).

o Site Template - Bạn phải xác định một site template mà các project portal được dựa vào đó. Site template này cũng phải có sẵn trên TFS SharePoint Portal. Site templates không bao gồm trong process template.

o Document Libraries - Sau khi project portal được tạo, bạn có thể xác định là additional các document libraries bổ sung được tạo.

o Folders and Files - Sau khi project portal được tạo, bạn có thể chỉ rõ additional folders thư mục bổ sung để tạo. Bạn cũng có thể xác định các file để copy như là các template file.

Version Control XML - Process definition file có tên là VersionControl.xml và được đặt trong Version Control folder trong process template folder hierarchy. Nó xác định một team project's initial version control security permissions, check-in notes, và whether exclusive check-out là bắt buộc.

o Check-in Notes - Xác định dù xem có bao gồm các check-in notes hay không. Check-in notes được cung cấp bởi developer nhà lập trình khi code được check in để mô tả nó như thế nào, hay nếu, code changes liên quan đến các team process. Thí dụ, một check-in note có thể cho biết nếu change là một phần của security review, và có thể cho biết bao gồm các chi tiết về các change liên quan đến security review.

o Exclusive Check-out - Được sử dụng để điều khiển dù xem có thể có nhiều user có thể check out một file tại cùng một thời điểm . hay không.

o Permissions - Xác định các actions security group và các individual có thể thực hiện trên các item bên dưới các version control.

Reports XML - Process definition file Tập tin định nghĩa quy trình này có tên là ReportsTasks.xml và được đặt trong thư mục Reportsfolder trong hệ phân cấp các thư mục process templatefolder hierarchy. Nó xác định các report ban đầu của dự án nhóm(team project's initial reports). óm.

o Reports Site - The reporting site Trang report có một liên kết đến nó, labeled Reports, trên project portal home page.

o Folders - Bạn có thể tạo các folder ácthư mục trên reporting sitetrang report. Các folder thư mục bạn tạo sẽ xuất hiện trên trang project site và ở bên dưới thư mục Reports folder trong Team Explorer.

o Reports - Được sử dụng để thêm các report bằng cách sử dụng các .rdl file.

Groups and Permissions XML - Process definition file Tập tin định nghĩa quy trình này có tên là GroupsandPermissions.xml và được đặt trong thư mục Groups and Permissionsfolder trong hệ phân cấp các thư mục process templatefolder hierarchy. Dùng để xác định các team project's initial security groups . ban đầu của dự án nhóm.

o Groups - Được sử dụng để xác định một TFS security group mới.

o Permissions - Được sử dụng để xác định các permission cho mỗi group bạn chỉ rõ.

New Team Project Wizard

Bạn sử dụng New Team Project Wizard để tạo mới các team project. Wizard sử dụng các plug-in và các tập tin XML process definition files xác định quy trình để tạo project.

Customization Approach

Phương pháp tùy chỉnh

Để tùy chỉnh một process template, hãy thực hiện các bước sau:

1. Xem lại các process template được TFS cung cấp và chọn một cái phù hợp nhất với process nhóm bạn tổ chức.

2. Download phần process template đã chọn.

3. Tùy chỉnh các thành phần khác nhau của process template.

4. Upload các template đã tùy chỉnh lên TFS.

5. Xác định rõ các thay đổi phù hợp với các yêu cầu quy trình của nhóm bạn.

Bản chất cách tiếp cận này được sử dụng như một phần của các solution sau đối với việc tùy chỉnh các process template:

Manually customize the XML files. Tùy chỉnh bằng tay rất dễ bị lỗi nhưng vẫn cho phép bạn dễ dàng điều khiển kiểm soát dựa trên việc tùy chỉnh các quy trình mẫu(process template)mẫu. Để có thêm thông tin, hãy xem "Customizing Process Templates" tại http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx

Process Template Editor Tool available with Power tools. Version mới nhất của Visual Studio 2005 Team Foundation Server Power Tool - một tập các enhancements(cải tiến), tools, và các tiện ích command-line utilities sẽ nâng cao kinh nghiệm về TFS - cung cấp một graphical tool(ccông cụ đồ họa ) cho để xem xét và chỉnh sửa các process templates. Khi kết nối đến TFS, bạn có thể sử dụng tool này để điều chỉnh cácdanh sách định nghĩa các work item type definitions và danh sách global lists trên một project hoạt động. Để có thêm thông tin, hãy xem "Làm thế nào: Tùy chỉnh một Process Template trong Visual Studio Team Foundation Server"

Các tùy chỉnh thông thường

Sau đây là những miêu tả về các thành phần mà bạn sẽ thường tùy chỉnh để tạo ra quy trình cho riêng mình:

Groups and Permissions. Các process templates có một tập các group với các permission khác nhau được phân cho chúng. Nếu các group và permission mặc định liên kết với những template này không được đầy đủ hay phù hợp với các yêu cầu của quy trình của bạn, bạn có thể update các group này hay tạo các group mới. Bạn cũng có thể thêm các individual user cho một group, remove các user từ một group, hay cấp hoặc thu hồi các permissions cho một group.

Source Control Check-In Notes and Policies. Process templates có một tập các Source Control Check-In notes và Policies. Nếu các check-in notes mặc định không đáp ứng đầy đủ hay phù hợp với các process requirement của bạn, bạn có thể thêm hay remove các check-in note fields, hay tạo ra một số các fields required và những cái khác thì không. Nếu các check-in policies mặc định không đáp ứng đầy đủ hay phù hợp, bạn có thể add, update, hay delete individual check-in policies.

Areas and Iterations. Process templates không cung cấp một phân loại cấu trúc cho cả các area hay iteration. Bạn có thể tùy chỉnh các area và iteration tùy theo các process requirement cụ thể của bạn. Phương pháp được đề nghị là để phân chia ra các area dựa trên các thành phần hay các chức năng của project. Các Iteration có thể dựa trên các chu kì thời gian cơ bản mà bạn sẽ lặp lại đặc biệt là tập các hoạt động chính (như là plan, develop, và test).

Team Portal. Các process templates cung cấp một tập các team portal mặc định, mà có thể là central hub cho sự giao tiếp giữa các team member và các thành viên khác trong tổ chức. Bạn có thể chỉnh sửa team portal để thay đổi sự xuất hiện của nó, hành vi cách thức hoạt động và nội dung cho phù hợp với các yêu cầu về quy trình của bạn.

Process Guidance. Các process templates cung cấp sách hướng dẫn quy trình liên quan để giải thích về các roles, forms, reports, và workflow được sử dụng trong team project. Khi tùy chỉnh các process template để đáp ứng các yêu cầu đòi hỏi, bạn phải chỉnh sửa process guidance để đối chiếu các thay đổi cho các thành phần khác nhau.

Reports. Các process templates cung cấp một tập các report mặc định. Nếu các report mặc định không phù hợp hay không đầy đủ, bạn có thể tạo các report cho riêng bạn dựa trên các requirement yêu cầu của bạn.

Work Item Types and Queries. Các process templates có một tập các Work item types, các work item instances và queries mặc định. Nếu các Work item types, work item instances và queries mặc định không đáp ứng đầy đủ hay không phù hợp với các yêu cầu về quy trình của bạn, bạn có thể tùy chỉnh các work item types cho phù hợp với các workflow hay các loại khác của các work item của bạn mà bạn muốn theo dõi. Thí dụ, bạn có thể:

o Thêm mới các work item types.

o Remove các work item types đã có.

o Thêm các work item type instances mặc định.

o Remove các work item type instances mặc định.

o Tạo các public hay private queries cho riêng bạn.

Bạn cũng có thể chỉnh sửa một work item type đã có; thí dụ:

o Add các field.

o Rename các field.

o Hạn chế danh sách các value của các field cho phép.

o Thay đổi các state và hỗ trợ các state transitions.

o Tạo các field được yêu cầu hay read-only.

o Tạo một field phụ thuộc vào một cái khác.

o Tự động populate các field value.

o Sắp xếp lại sự xuất hiện của các thông tin trên form.

o Thay đổi Microsoft Office Project column mà một certain field được map.

Các quy quá trình tùy chỉnh làm việc như thế nào?

Tùy chỉnh một process template bao gồm các bước sau:

1. Người sử dụng khởi chạy New Team Project Wizard.

2. Và wizard yêu cầu:

o Tên của team project.

o Process template được sử dụng khi tạo một team project.

Các screen được hiển thị trong wizard được xác định bởi các plug-in được sủ sử dụng. Thí dụ, nếu một process template không bao gồm Windows SharePoint Services plug-in, không có screen hiển thị để hỏi thông tin về project portal.

3. Sau khi user cung cấp thông tin cho các wizard request và click Finish, wizard sẽ thực hiện gọi đến các plug-in để thực thi công việc khởi tạo team project. Thứ tự của các plug-in được gọi được xác định bởi các tập tin XML định nghĩa các quy trình.

4. Trình wizard đọc các hướng dẫn được chứa trong process template và sau đó khởi tạo và cấu hình các item cụ thể. Người sử dụng không cần phải xác định bất cứ chi tiết nào về các loại work item khác nhau để tạo vì các hướng dẫn đã được cung cấp bởi các process template.

Lưu ý: Nếu trình wizard gặp phải một vấn đề trong khi tạo mới một team project, bạn sẽ thấy một tin nhắn thông báo lỗi miêu tả về vấn đề và đề nghị các hành động để sửa sai.

Tổng kết

Sử dụng MSF Agile process template nếu bạn đang triển khai một phương pháp nhanh chóng để build phần mềm của bạn. Sử dụng MSF CMMI nếu bạn đang theo phương pháp Software Engineering Institute (SEI) Capability Maturity Model Integration.

Những thành phần quan trọng nhất của kiến trúc process template là các process template plug-ins, XML process definition files, và New Team Project wizard.

Nếu các process template mặc định không thõa thỏa mãn các yêu cầu quy trình của bạn, bạn có thể tùy chỉnh các template bằng cách chỉnh sửa bằng tay các tập tin XML process definition, hay bạn có thể sử dụng công cụ Process Editor Tool để chỉnh sửa các process template.

Phần area phổ biến nhất của sự tùy chỉnh là các group và các permission, source control check-in notes và policy, areas và iteration, reports, và work item type definitions.

Tài nguyên bổ sung

Để có thêm thông tin về việc chọn một process template, hãy xem "Choosing a Process Template" tại http://msdn2.microsoft.com/en-us/library/ms400752(vs.80).aspx

Để download MSF CMMI process template, hãy xem http://www.microsoft.com/downloads/details.aspx?FamilyID=12A8D806-BB98-4EB4-BF6B-FB5B266171EB&displaylang=en

Để download the MSF Agile process template, hãy đến http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F-48FB-824E-828BF593C34D&displaylang=en

Để có thêm thông tin về process template customization, hãy xem "Process Template Customization Overview" tại http://msdn2.microsoft.com/en-us/library/ms194945(VS.80).aspx

Để download the Team Foundation Server Power Tools bao gồm Process Template Editor, hãy đến http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx

Để xem lại process templates được Microsoft Partners cung cấp, hãy xem tại http://msdn2.microsoft.com/en-us/teamsystem/aa718801

Chương 13 – Giải thích về Process Templates

Nguyễn Thị Như Quỳnh — Wed, 25 Nov 2009 13:17:49 GMT
Revision 2 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 11/25/2009 9:17:49 PM

Chương 12 - 13 – Giải thích về các Work ItemProcess Templates

Filed under: TFS

Chủ đề

Tìm hiểu về mục đích, nội dung và cấu trúc và mục đích của các work itemsprocess templates.

Mô tả work item workflow

Học về sự khác nhau chính giữa Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) và MSF for CMMI® Process Improvements (MSF CMMI) process templates.

Tùy chỉnh các work item process template để đáp ứng những nhu cầu cụ thể của nhóm team của bạn.

Xem trước

Chương này giới thiệu cho bạn giải thích vai trò của các work item process template trong Microsoft Visual Studio® 2005 Team Foundation Server (TFS). Nó xác định các chức năng chính và giải sự khác nhau chính giữa hai process templates được cung cấp: MSF Agile và MSF CMMI.

Các quy trình phát triển phần mềm(software-development processes) thích bằng ì phức tạp, liên quan đến nhiều mức độ của cách ác hoạt động phụ thuộc lẫn nhau. Những quy trình nào bạn ày nói chung là có sẵn cho các nhóm phát triển trong các dạng tài liệu nhưng thường không được các tool thực hiện. Việc không hỗ trợ của tool này gây khó khăn cho các nhóm phát triểm để tìm hiểu và làm theo các quy trình một cách nhất quán. Các project manager có thể sử dụng nhiều tool khác nhau cho việc quản lý project, requirement management(quản lý các yêu cầu), bug tracking(theo dõi các lỗi), hay review management và chúng thường không được tích hợp tốt. Thiếu sự thống nhất này gây khó khăn hơn trong việc thực thi một phương pháp phù hợp giữa các project và để giúp quản tạo ra các report thích hợp để thúc đẩy hiểu biết đồng bộ trong toàn đội nhóm về tiến độ và tình hình dự án. Thiếu sự nhất quán này có thể dẫn đến việc lí àm cho quá trình phân tích thiếu độ tin cậy, sẽ làm khó khăn hơn trong việc xác định và thực thi cải tiến các software development project của bạnquy trình theo thời gian.Mỗi work item đại diện cho

Visual Studio Team System (VSTS) và TFS cung cấp một unit of work môi trường tích hợp để được hỗ trợ hầu hết các quy trình hoạt động có liên quan đến một dự án phát triển phần mềm. TFS thực hiện bởi development team thi phướng pháp vòng đời(life-cycle methodologies) của bạnnó qua cách sử dụng các process templates. Một process template là một tập các loại work item type được định nghĩa trong file Extensible Markup Language (XML) cung cấp các chi tiết kĩ thuật cho các process template mvà bạn chọn khi các artifact tạo mới nên một team projectphương pháp phát triển(development methodology).

Sau khi project Chương này giải thích kiến trúc của bạn được khởi động, bạn một quy trình mẫu(process template) và các thành phần của nó thể tạo bất kì available work item type để theo dõi những nỗ lực bạn hiểu hơn về cách thức làm việc. Trong khi các work item type mặc định sao để sử dụng và behaviour tùy chỉnh các process template được định nghĩa trong cung cấp.

Nếu các process templates, bất kì khía cạnh nào của work item type đều template đã có thể được chỉnh sửa để fit tốt hơn phương không pháp làm việc ù hợp với quy trình phát triển của nhóm của bạn, bạn có thể tạo một process template mới, chỉnh sửa các template có sẵn, hoặc chọn từ các process templates được cung cấp bởi Microsoft Partners. Để xem các process templates được cung cấp bởi Microsoft Partners, hãy xem: http://msdn2.microsoft.com/en-us/teamsystem/aa718801

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

Sử dụng chương này để tìm hiểu kiến trúc process template , cấu trúc, và sự tùy biến(customization). Để đạt có được những lợi ích tốt nhất từ chương này, bạn nên:

Đọc phần "Work Item Structure" để "MSF Agile and MSF CMMI Process Templates". Để tìm hiểu về các work item types đã được xác process template mặc định trước và bằng các work item workflow được định nghĩa như thế ách nào.ào để chọn template mà phù hợp nhất với nhu cầu của nhóm bạn.

Đọc phần "Customizing Work ItemsProcess Guidance"để . Để tìm hiểu làm thế nào và tại sao bạn nên cách thức tùy chỉnh work item typecác process template đã có để phù hợp với nhu cầu của nhóm bạn hơn.

Tình huống
MSF Agile and MSF CMMI Process Templates

Team Foundation Server đi kèm với hai process template: MSF Agile and MSF CMMI. Hai process templates này hướng và Giải pháp

Cào hai phong cách khác work item là những nhau của phát triển phần mềm. Bạn nên sử dụng MSF Agile nếu bạn đang triển khai một phương pháp chính mà các project manager nhanh(agile methodology) để thiết kế phần mềm của bạn. MSF Agile khuyến khích test-driven development và các team leader thực hành agile khác. Bạn nên sử dụng MSF CMMI nếu bạn đang theo dõi công việc đuổi phương pháp Software Engineering Institute (SEI) Capability Maturity Model® Integration. Đây là những việc còn lại cần được thực hiện trên một project, cũng như quy trình chính thức(formal process) nhằm cải thiện công việc ác quy trình phát triển đã được hoàn thành. có.

Các team member sử dụng template khác nhau trong những gì mà chúng được cung cấp. Thí dụ, chúng tạo ra các loại report mặc định và các loại work item để theo dõi khác nhau. Những template công việc ó thể dễ dàng được chỉnh sửa cho phù hợp với cá nhân ác nhu cầu của họ queue vproject của bạn.

Customizing Process Guidance

Project mà phân công bạn đang tạo có thể không việc đến phù hợp với các thành viên process template được cung cấp với VSTS. Bạn có thể cần một loại work item khác vhay bạn đang sử dụng một process methodology hoàn toàn khác. Thí dụ, nếu bạn đang sử dụng SCRUM không đề cập đến các sprint trong dạng lỗi hay các nhiệm vụ.

Sau đây là process template hiện có. Trong trường hợp này bạn cần sửa đổi hoặc thay thế các process template đã cách ó cho phù hợp với phương pháp luận(methodology) mà nhóm bạn sử dụngcác work item chung .

Process Template Architecture

Có ba phần quan trọng trong kiến trúc của process template:

• Process template plug-ins

• XML process definition files

• New Team Project Wizard

Process Template Plug-ins

Các process template plug-in là các thành phần mà run khi một team project :

Tạo mới được tạo. Một plug-in thiết lập các user requirement hay Quality of Service (QoS) requirements tập tin file cần thiết và cấu hình data cho một ứng dụngkhu vực cụ thể(specific area) của template.

Theo dõi phát triển Các plug-in sau thì available out-of-box với TFS.

Classification - Xác định một team project's initial iteration và kiểm thử đối với careas(các requirement.

Tạo vùng và các development task để đại diện cho công việc cần được hoàn thành để thực thi ckhởi tạo ban đầu của dự án nhóm).

Groups and Permissions - Xác thành phần định một team project's initial security groups và chức năng của ứng dụng.

Tạo các bug để đại diện cho cpermission của chúng.

Windows SharePoint Services - Xác khuyết tật(defect) trong khi thực thi định project portal cho team dựa trên một Microsoft Windows SharePoint® site template. Nó cũng định nghĩa các thành phần template file và chức năng của ứng dụngprocess guidance.

Phân loại bug(lỗi)

Work Item Tracking - Xác định một team project's initial work item types, queries, và task(nhiệm vụ) để họ được ưu tiên(prioritized) work

item instances.

Reports - Xác định một team project's initial reports và thiết lập cân bằng(balanced) ác report site.

Version Control -Xác định một team project's initial version control security permissions, và các tương thích trên toàn độicheck-in notes.

Theo dõi

Bạn các development task ó thể chỉnh sửa mỗi plug-in definition file để xác định những hướng tiến bộ về tình trạng hoàn thiện codeùy chỉnh một process template.

Theo dõi Ngoại trừ các bug classification plug-in, bạn cũng cùng với ó thể delete plug-in definition files để tùy chỉnh một process template.

XML Process Definition Files

The XML process definition files là một tập các số liệu chất lượng khác, để tập tin XML xác định chất lượng của ứng dụng vmột tập các task(nhiệm vụ) mà sự sẵn sàng cần được run để cấu hình chính xác một team project mới cho process. Khi bạn sử dụng New Team Project Wizard để tạo một team project, nó chạy yêu cầu các plug-in. Mỗi plug-in đọc các XML process definition file tương ứng của nó để thu được di chuyểndanh sách các task mà nó phải run.

Bạn sẽ Bằng cách sử dụng các work item dựa trên các work item type được định nghĩa cho project của XML process definition files, bạn như thế nào. Sự xác định nghĩa rõ các work item được lưu trữ trong process template cấu hình và cài đặt gì mà bạn các plug-in phải thực thi. Sau đã chọn khi tạo team project của bạn lần đầu tiên. Bạn ây là có thể chọn một trong hai templates mặc địnhác chi tiết về các XML file:

Work Item Tracking XML - Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) hay MSF for CMMI® Process Improvement (MSF CMMI) - hay bạn definition file này có thể tùy chỉnh ên là Workitems.xml và được đặt trong thư mục Work Item Tracking folder trong process template folder hierarchy. Có ba loại quan trọng của các task cần chỉ rõ: work item để đáp ứng cho types, work item queries, và work item instances.

o   Work Item Types - Xác định các nhu cầu rules, fields, states, và transitions cho một phần của các quy ông việc mà sẽ được theo dõi trình ên một team project như là các task, bug,và các requirements.

o   Work Item Queries - Được sử dụng để tìm kiếm các group cụ thể của nhóm bạncác work item, như là các task hay các active bug.

Cấu trúc Các work item query được xác định trong các work item query (WIQ) files trong thư mục Queries folder bên dưới Work Item

Mỗi Tracking folder trong process template folder hierarchy.

o   Work Item Instances - Tập ban đầu các work item type instances được tạo mặc định khi bạn tạo team project.

Classification XML - Process definition file này có thể tên là Classification.xml và được định nghĩa như sau:

• đặt trong Classification folder trong process template folder hierarchy. Nó bao gồm có một mục đích hai phần: Iterations và ý định sử dụngAreas.Đối với trường hợp, các bug(lỗi) được

o Iterations - Được sử dụng để theo dõi chất lượng cxác defect(khuyết tật), định số lần mà team sẽ repeat một tập đặc biệt các task major activities (như là plan, develop, test). Iterations ảnh hưởng đến work item query và report bởi vì iterations được sử dụng để theo dõi nhóm các scheduled work items.

o Areas - Được sử dụng để tổ chức công việc trong team project. Thí dụ, QoS requirements một team có thể tổ chức công việc dựa trên sản phẩm hay chức năng, như là UI area, Application area, và

Database area. Areas được sử dụng để nắm bắt nhóm các khía cạnh non-functional quan trọng như work items cho các query và các report.

Windows SharePoint Services XML - Process definition file có tên là bảo mật( security) WssTasks.xml và thực thi cđược đặt trong Windows SharePoint Services folder trong process template folder hierarchy. Có ba task quan trọng để xác yêu cầu(performance requirement)định rõ: Site Template (site template nào để sử dụng), Document Libraries (document libraries nào để tạo), và vv..Folders and Files ( folders and files nào để copy vào document libraries).

Nó

o Site Template - Bạn phải xác định một site template mà các project portal được dựa vào đó. Site template này cũng phải có một workflow(tiến sẵn trình cên TFS SharePoint Portal. Site templates không việc) bao gồm trong process template.

o Document Libraries - Sau khi project portal được định nghĩa bởi tạo, bạn có thể xác state vđịnh là transitionadditional document libraries được tạo. Thí dụ

o Folders and Files - Sau khi project portal được tạo, giai đoạn từ "Opened" đến "Resolved" đến trạng thái "Closed".

Nbạn có thể chỉ rõ additional folders để tạo. Bạn cũng có một tập thể xác định các field mfile để copy như là các template file.

Version Control XML - Process definition file có thể tên là VersionControl.xml và được cài đặt trong Version Control folder trong process template folder hierarchy. Nó xác định một team project's initial version control security permissions, truy vấncheck-in notes, và báo whether exclusive check-out là bắt buộc.

o Check-in Notes - Xác định dù cáo. ó bao gồm các check-in notes hay không. Check-in notes được cung cấp bởi developer khi code được check in để mô tả nó như thế nào, hay nếu, code changes liên quan đến các team process. Thí dụ, Prioritymột check-in note có thể cho biết nếu change là một phần của security review, Status và, Iterationà có thể cho biết bao gồm các chi tiết về các change liên quan đến security review.

Work Item Types

The MSF Agile

o Exclusive Check-out - Được sử dụng để điều khiển dù có nhiều user có thể check out một file tại cùng một thời điểm.

o Permissions - Xác định các actions security group và MSF CMMI process templates mỗi loại định nghĩa một tập các work individual có thể thực hiện trên các item mà ánh xạ(map) đến bên dưới các roles version control.

Reports XML - Process definition file này có tên là ReportsTasks.xml và activities được định nghĩa đặt trong Reports folder trong process guidancetemplate folder hierarchy.

MSF Agile Work Item Types

MSF Agile chứa Nó xác định các work item type sau:

Bug. Đại diện một problem hay potential problem trong ứng dụng report ban đầu của bạn.

Riskdự án nhóm(team project's initial reports). Đại diện

o Reports Site - The reporting site có một event hay điều kiện liên kết đến nó, labeled Reports, trên project

portal home page.

o Folders - Bạn có thể mtạo các folder trên reporting site. Các folder bạn tạo sẽ xuất hiện trên project site và ở bên dưới Reports folder trong Team Explorer.

o Reports - Được sử dụng để thêm các report bằng cách sử dụng các .rdl file.

Groups and Permissions XML - Process definition file có tên là GroupsandPermissions.xml và được đặt trong Groups and Permissions folder trong process template folder hierarchy. Dùng để xác động tiêu cực đến định các team projectcủa 's initial security groups.

o Groups - Được sử dụng để xác định một TFS security group mới.

o Permissions - Được sử dụng để xác định các permission cho mỗi group bạn chỉ rõ.

New Team Project Wizard

Bạn sử dụng New Team Project Wizard để tạo mới các team project.

ScenarioWizard sử dụng các plug-in và XML process definition files để tạo project. Đại diện một đường dẫn duy nhất của sự tương

Customization Approach

Để tùy chỉnh một process template, hãy thực hiện các của user thông qua hệ thống.

Taskbước sau:

1.Đại diện nhu cầu cho Xem lại các process template được TFS cung cấp và chọn một cái phù hợp nhất với process nhóm bạn tổ chức.

2. Download phần process template đã chọn.

3. Tùy chỉnh các thành viphần khác nhau của process template.

4. Upload các template đã tùy chỉnh lên TFS.

5. Xác định rõ các thay đổi phù hợp với các yêu cầu quy trình của nhóm để làm bạn.

Bản chất cách tiếp cận này được sử dụng như một số phần của các solution sau đối với việc tùy chỉnh công ác process template:

Manually customize the XML files. Tùy chỉnh bằng tay rất dễ bị lỗi nhưng vẫn cho phép bạn dễ dàng điều khiển dựa trên việc tùy chỉnh các quy trình mẫu(process template).

Quality of Service RequirementĐể có thêm thông tin, hãy xem "Customizing Process Templates" tại http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx

Process Template Editor Tool available with Power tools. Đại diện Version mới nhất của Visual Studio 2005 Team Foundation Server Power Tool - một yêu cầu(requirement) ràng buộc mtập các enhancements(cải tiến), tools, và hệ thống command-line utilities sẽ nên làm việc như thế âng cao kinh nghiệm về TFS - cung cấp một graphical tool(công cụ đồ họa) cho xem xét và chỉnh sửa process templates. Khi kết nối đến TFS, bạn có thể sử dụng tool nào.

MSF CMMI Work Item Types

MSF CMMI contains the following ày để điều chỉnh các work item types:

Bugtype definitions và global lists trên một project hoạt động. Đại diện Để có thêm thông tin, hãy xem "Làm thế nào: Tùy chỉnh một problem hay potential problem Process Template trong ứng dụng của Visual Studio Team Foundation Server"

Các tùy chỉnh thông thường

Sau đây là những miêu tả về các thành phần mà bạn .

Change Request. Đại diện sẽ thường tùy chỉnh để tạo ra quy trình cho riêng mình:

Groups and Permissions. Các process templates có một thay đổi tập các group với các permission khác nhau được đề nghị đến ứng dụng phân cho chúng. Nếu các group và permission mặc định liên kết với những template này không được đầy đủ hay phù hợp với các yêu cầu của quy trình của bạn.

Issue, bạn có thể update các group này hay tạo các group mới. Đại diện Bạn cũng có thể thêm các individual user cho một tình huống mà block group, remove công việc ác user từ một group, hay hiện tại là blocking workcấp hoặc thu hồi các permissions cho một group.

Requirement

Source Control Check-In Notes and Policies. Đại diện Process templates có một sự miêu tả tập các Source Control Check-In notes vè những gì mà Policies. Nếu các check-in notes mặc định không đáp ứng dụng đầy đủ hay phù hợp với các process requirement của bạnnên làm để giải quyết một customer problem.

Review. Đại diện , bạn có thể thêm hay remove các kết quả của check-in note fields, hay tạo ra một sự xem lại codesố các fields required và những cái khác thì không. Nếu các check-in policies mặc định không đáp ứng đầy đủ hay phù hợp, design(thiết kế)bạn có thể add, update, hay deployment(sự triển khai)delete individual check-in policies.

Risk

Areas and Iterations. Đại diện Process templates không cung cấp một event phân loại cấu trúc cho cả các area hay điều kiện iteration. Bạn có thể mà tùy chỉnh có ác area và iteration tùy theo các động tiêu cực đến project process requirement cụ thể của bạn

Task. Đại diện cho những như cầu của một Phương pháp được đề nghị là để phân chia ra các area dựa trên các thành viên phần hay các chức năng của nhóm để thực hiện một số việcproject.

Work Item Workflow

Mỗi work item Các Iteration có thể dựa trên các chu kì thời gian cơ bản mà bạn sẽ lặp lại đặc biệt là tập các hoạt động chính (như là plan, develop, và test).

Team Portal. Các process templates cung cấp một workflow được tập các team portal mặc địnhnghĩa trước đại diện một state(tình trạng) , mà work item có thể có trong cũng như là quá trình chuyển đổi(transition) central hub cho sự giao tiếp giữa các state. Mỗi state được liên kết một team member và cách tự nhiác thành viên với một role trong TFS. Thí dụ khi một tester mở một bug mới khác trong MSF Agile thì state là Activetổ chức. Khi một developer Bạn có thể chỉnh sửa lỗi thì state của bug được team portal để thay đổi thành Resolved. Khi tester thẩm tra việc sửa lỗi thì bug state chuyển thsự xuất hiện của nó, hành Closed.

Workflow Examples

Thí dụ sau hiển thị workflow vi và nội dung cho hai loại work item types phổ biến.

MSF CMMI Task

Một MSF CMMI task có thể có phù hợp với các state sau:

Proposed. Thí dụ, proposed bởi một developer, tester, hay architectyêu cầu về quy trình của bạn.

Active

Process Guidance. Thí dụ Các process templates cung cấp sách hướng dẫn quy trình liên quan để giải thích về các roles, accepted bởi một lead hay manager.

Resolved. Thí dụforms, resolved bởi một developer.

Closed. Thí dụreports, tested và closed bởi một testerworkflow được sử dụng trong team project.

Hình 12.1 hiển thị mỗi state cùng với sự chuyển đổi có thể giữa Khi tùy chỉnh các state

MSF Agile Bug

Một MSF Agile Bug process template để đáp ứng có thể ác yêu cầu đòi hỏi, bạn phải chỉnh sửa process guidance để đối chiếu có ác thay đổi cho các state sau:

Active. Thí dụ, opened bởi một tester.

Resolved. Thí dụ, resolved bởi một developerthành phần khác nhau.

Closed

Reports. Thí dụ, tested và closed bởi Các process templates cung cấp một testertập các report mặc định.

Hình 12.2 hiển thị mỗi state Nếu cùng với sự chuyển đổi ác report mặc định không phù hợp hay không đầy đủ, bạn có thể giữa tạo các statereport cho riêng bạn dựa trên các requirement của bạn.

Tùy chỉnh

Work ItemsItem Types and Queries. Các process templates có một vài tập các kịch bản(scenarios) mà bạn có thể muốn chỉnh sửa Work item types, các work item type được instances và queries mặc địnhnghĩa trong MSF Agile hay MSF CMMI:

Một . Nếu các Work item types, work item instances và queries mặc định không đã bị thiếu mất một field quan trọng cho áp ứng đầy đủ hay không phù hợp với các yêu cầu về quy trình phát triển của bạn.

Một , bạn có thể tùy chỉnh các work item workflow không types cho phù hợp với cách thức làm việc của nhóm bạn.

• Bạn cần một ác workflow hay các loại work item mới.

Để hỗ trợ cho khác của các kịch bản này, work item của bạn mà bạn muốn theo dõi. Thí dụ, bạn có thểthực hiện :

o Thêm mới các việc sau trong TFS:

Add/remove work item types: .

o Remove các work item types đã có.

o Thêm/ gỡ bỏ êm các loại work item type instances mặc định.

Modify fields in existing work items: Thay đổi

o Remove các field trong work item type instances mặc định.

o Tạo các public hay private queries cho riêng bạn.

Bạn cũng có thể chỉnh sửa một work item type đã có.

Modify states and transitions in existing work itemsó; thí dụ:Chỉnh sửa

o Add các field.

o Rename các field.

o Hạn chế danh sách các value của các field cho phép.

o Thay đổi các state và transition trong hỗ trợ các work item đã state transitions.

o Tạo có.

Để ác field được yêu cầu hay read-only.

o Tạo một field phụ thuộc vào một có thêm ái khác.

o Tự động populate các field value.

o Sắp xếp lại sự xuất hiện của các thông tin về customizing work items, hãy xem "How To: Customize a Process Template in Visual Studio Team Foundation Servertrên form. "

Tổng kết

o Thay đổi Microsoft Office Project column mà một certain field được map.

Các work item được sử dụng bởi quy trình tùy chỉnh làm việc như thế nào?

Tùy chỉnh một process template bao gồm các project manager vbước sau:

1. Người sử dụng khởi chạy New Team Project Wizard.

2. Và các wizard yêu cầu:

o Tên của team leader để theo dõi cong việc project.

o Process template được thực hiện trên sử dụng khi tạo một team project.Họ thường tạo

Các screen được hiển thị trong wizard được xác định bởi các development task(nhiệm vụ phát triển) plug-in được sủ dụng. Thí dụ, nếu một process template không bao gồm Windows SharePoint Services plug-in, không có screen hiển thị để đại diện hỏi thông tin về project portal.

3. Sau khi user cung cấp thông tin cho các wizard request và click Finish, wizard sẽ thực hiện gọi đến các plug-in để thực thi công việc cần được hoàn thành, khởi tạo team project. Thứ tự của các bug để đại diện plug-in được gọi được xác định bởi các khuyết tật(defect) tập tin XML định nghĩa các quy trình.

4. Trình wizard đọc các hướng dẫn được chứa trong sự thực thi process template và sau đó khởi tạo và cấu hình các user requirement hay Quality of Service (QoS) requirementsitem cụ thể. Ngoài ra, chúng còn được Người sử dụng để theo dõi không cần phải xác định bất cứ chi tiết nào về các development loại work item khác nhau để tạo và testing against requirementsì các hướng dẫn đã được cung cấp bởi các process template.

Lưu ý: Nếu trình wizard gặp phải một vấn đề trong khi tạo mới một team project, bạn sẽ thấy một tin nhắn thông báo lỗi miêu tả về vấn đề và để xđề nghị các định chất lượng của ứng dụng và mức độ sẵn sàng của nó hành động để di chuyểnsửa sai.

The

Tổng kết

Sử dụng MSF Agile và process template nếu bạn đang triển khai một phương pháp nhanh chóng để build phần mềm của bạn. Sử dụng MSF CMMI nếu bạn đang theo phương pháp Software Engineering Institute (SEI) Capability Maturity Model Integration.

Những thành phần quan trọng nhất của kiến trúc process templates cung cấp một tập template là các work item type process template plug-ins, XML process definition files, và New Team Project wizard.

Nếu các process template mặc định . Bạn không thõa mãn các yêu cầu quy trình của bạn, bạn có thể tùy chỉnh những cái này hay tạo mới ác template bằng cách chỉnh sửa bằng tay các work item types tập tin XML process definition, hay bạn có thể sử dụng Process Editor Tool để đáp ứng chỉnh sửa các process requirement template.

Phần area phổ biến nhất của bạnsự tùy chỉnh là các group và các permission, source control check-in notes và policy, areas và iteration, reports, và work item type definitions.

Tài nguyên bổ sung

Để có thêm thông tin về work itemviệc chọn một process template, hãy xem "Managing Team Foundation Work Items"Choosing a Process Template" tại http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspxhttp://msdn2.microsoft.com/en-us/library/ms400752(vs.80).aspx

Để download MSF CMMI process templatevà xem lại các available work item types,h, hãy xem tại http://www.microsoft.com/downloads/details.aspx?FamilyID=12A8D806-BB98-4EB4-BF6B-FB5B266171EB&displaylang=en

Để download the MSF Agile process templatevà xem lại available work item types, hãy đến http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F-48FB-824E-828BF593C34D&displaylang=en

Để có thêm thông tin về process template customization, hãy xem "Process Template Customization Overview" tại http://msdn2.microsoft.com/en-us/library/ms194945(VS.80).aspx

Để download the Team Foundation Server Power Tools bao gồm Process Template Editor, hãy đến http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx

Để xem lại process templates được Microsoft Partners cung cấp, hãy xem tại http://msdn2.microsoft.com/en-us/teamsystem/aa718801

Chương 12 - Giải thích về các Work Item

Nguyễn Thị Như Quỳnh — Wed, 25 Nov 2009 13:13:45 GMT
Revision 1 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 11/25/2009 9:13:45 PM

Chủ đề

Tìm hiểu về cấu trúc và mục đích của các work items.

Mô tả work item workflow.

Tùy chỉnh các work item để đáp ứng những nhu cầu cụ thể của nhóm của bạn.

Xem trước

Chương này giới thiệu cho bạn các work item và giải thích bằng cách nào bạn có thể sử dụng chúng để giúp quản lí các software development project của bạn. Mỗi work item đại diện cho một unit of work để được thực hiện bởi development team của bạn. Một tập các loại work item type được định nghĩa trong process template mà bạn chọn khi tạo mới một team project.

Sau khi project của bạn được khởi động, bạn có thể tạo bất kì available work item type để theo dõi những nỗ lực làm việc. Trong khi các work item type mặc định và behaviour được định nghĩa trong các process templates, bất kì khía cạnh nào của work item type đều có thể được chỉnh sửa để fit tốt hơn phương pháp làm việc của nhóm bạn.

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

Để đạt được những lợi ích tốt nhất từ chương này, bạn nên:

Đọc phần "Work Item Structure" để tìm hiểu về các work item types đã được xác định trước và các work item workflow được định nghĩa như thế nào.

Đọc phần "Customizing Work Items" để tìm hiểu làm thế nào và tại sao bạn nên tùy chỉnh work item type.

Tình huống và Giải pháp

Các work item là những phương pháp chính mà các project manager và các team leader theo dõi công việc là những việc còn lại cần được thực hiện trên một project, cũng như công việc đã được hoàn thành. Các team member sử dụng các work item để theo dõi công việc cá nhân của họ queue và phân công công việc đến các thành viên khác ví dụ, trong dạng lỗi hay các nhiệm vụ.

Sau đây là các cách sử dụng các work item chung trong các team project:

Tạo các user requirement hay Quality of Service (QoS) requirements cho một ứng dụng.

Theo dõi phát triển và kiểm thử đối với các requirement.

Tạo các development task để đại diện cho công việc cần được hoàn thành để thực thi các thành phần và chức năng của ứng dụng.

Tạo các bug để đại diện cho các khuyết tật(defect) trong khi thực thi các thành phần và chức năng của ứng dụng.

Phân loại bug(lỗi) và task(nhiệm vụ) để họ được ưu tiên(prioritized) và cân bằng(balanced) một các tương thích trên toàn đội.

Theo dõi các development task để xác định những hướng tiến bộ về tình trạng hoàn thiện code.

Theo dõi các bug, cùng với các số liệu chất lượng khác, để xác định chất lượng của ứng dụng và sự sẵn sàng của nó để được di chuyển.

Bạn sẽ sử dụng các work item dựa trên các work item type được định nghĩa cho project của bạn như thế nào. Sự định nghĩa các work item được lưu trữ trong process template mà bạn đã chọn khi tạo team project của bạn lần đầu tiên. Bạn có thể chọn một trong hai templates mặc định- Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) hay MSF for CMMI® Process Improvement (MSF CMMI) - hay bạn có thể tùy chỉnh các work item để đáp ứng cho các nhu cầu và các quy trình cụ thể của nhóm bạn.

Cấu trúc Work Item

Mỗi work item type có thể được định nghĩa như sau:

• Nó có một mục đích và ý định sử dụng. Đối với trường hợp, các bug(lỗi) được sử dụng để theo dõi chất lượng các defect(khuyết tật), các task được sử dụng để theo dõi các scheduled work, QoS requirements được sử dụng để nắm bắt các khía cạnh non-functional quan trọng như là bảo mật( security) và thực thi các yêu cầu(performance requirement), và vv...

Nó có một workflow(tiến trình công việc) được định nghĩa bởi các state và transition. Thí dụ, giai đoạn từ "Opened" đến "Resolved" đến trạng thái "Closed".

Nó có một tập các field mà có thể được cài đặt, truy vấn, và báo cáo. Thí dụ, Priority, Status và, Iteration.

Work Item Types

The MSF Agile và MSF CMMI process templates mỗi loại định nghĩa một tập các work item mà ánh xạ(map) đến các roles và activities được định nghĩa trong process guidance.

MSF Agile Work Item Types

MSF Agile chứa các work item type sau:

Bug. Đại diện một problem hay potential problem trong ứng dụng của bạn.

Risk. Đại diện một event hay điều kiện có thể mà có tác động tiêu cực đến project của bạn.

Scenario. Đại diện một đường dẫn duy nhất của sự tương tác của user thông qua hệ thống.

Task. Đại diện nhu cầu cho một thành viên của nhóm để làm một số các công việc.

Quality of Service Requirement. Đại diện một yêu cầu(requirement) ràng buộc mà hệ thống nên làm việc như thế nào.

MSF CMMI Work Item Types

MSF CMMI contains the following work item types:

Bug. Đại diện một problem hay potential problem trong ứng dụng của bạn.

Change Request. Đại diện cho một thay đổi được đề nghị đến ứng dụng của bạn.

Issue. Đại diện cho một tình huống mà block công việc hay hiện tại là blocking work.

Requirement. Đại diện một sự miêu tả vè những gì mà ứng dụng của bạn nên làm để giải quyết một customer problem.

Review. Đại diện các kết quả của một sự xem lại code, design(thiết kế), hay deployment(sự triển khai).

Risk. Đại diện một event hay điều kiện có thể mà có tác động tiêu cực đến project của bạn

Task. Đại diện cho những như cầu của một thành viên của nhóm để thực hiện một số việc.

Work Item Workflow

Mỗi work item có một workflow được định nghĩa trước đại diện một state(tình trạng) mà work item có thể có trong cũng như là quá trình chuyển đổi(transition) giữa các state. Mỗi state được liên kết một cách tự nhiên với một role trong TFS. Thí dụ khi một tester mở một bug mới trong MSF Agile thì state là Active. Khi một developer sửa lỗi thì state của bug được thay đổi thành Resolved. Khi tester thẩm tra việc sửa lỗi thì bug state chuyển thành Closed.

Workflow Examples

Thí dụ sau hiển thị workflow cho hai loại work item types phổ biến.

MSF CMMI Task

Một MSF CMMI task có thể có các state sau:

Proposed. Thí dụ, proposed bởi một developer, tester, hay architect.

Active. Thí dụ, accepted bởi một lead hay manager.

Resolved. Thí dụ, resolved bởi một developer.

Closed. Thí dụ, tested và closed bởi một tester.

Hình 12.1 hiển thị mỗi state cùng với sự chuyển đổi có thể giữa các state

MSF Agile Bug

Một MSF Agile Bug có thể có các state sau:

Active. Thí dụ, opened bởi một tester.

Resolved. Thí dụ, resolved bởi một developer.

Closed. Thí dụ, tested và closed bởi một tester.

Hình 12.2 hiển thị mỗi state cùng với sự chuyển đổi có thể giữa các state.

Tùy chỉnh Work Items

Có một vài các kịch bản(scenarios) mà bạn có thể muốn chỉnh sửa các work item type được định nghĩa trong MSF Agile hay MSF CMMI:

Một work item đã bị thiếu mất một field quan trọng cho quy trình phát triển của bạn.

Một work item workflow không phù hợp với cách thức làm việc của nhóm bạn.

• Bạn cần một loại work item mới.

Để hỗ trợ cho các kịch bản này, bạn có thể thực hiện các việc sau trong TFS:

Add/remove work item types: Thêm/ gỡ bỏ các loại work item.

Modify fields in existing work items: Thay đổi các field trong các work item đã có.

Modify states and transitions in existing work items: Chỉnh sửa các state và transition trong các work item đã có.

Để có thêm thông tin về customizing work items, hãy xem "How To: Customize a Process Template in Visual Studio Team Foundation Server."

Tổng kết

Các work item được sử dụng bởi các project manager và các team leader để theo dõi cong việc được thực hiện trên một project. Họ thường tạo các development task(nhiệm vụ phát triển) để đại diện cho các công việc cần được hoàn thành, khởi tạo các bug để đại diện các khuyết tật(defect) trong sự thực thi và tạo các user requirement hay Quality of Service (QoS) requirements. Ngoài ra, chúng còn được sử dụng để theo dõi các development và testing against requirements, và để xác định chất lượng của ứng dụng và mức độ sẵn sàng của nó để di chuyển.

The MSF Agile và MSF CMMI process templates cung cấp một tập các work item type mặc định. Bạn có thể tùy chỉnh những cái này hay tạo mới các work item types để đáp ứng các process requirement của bạn.

Tài nguyên bổ sung

Để có thêm thông tin về work item, hãy xem "Managing Team Foundation Work Items" tại http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx

Để download MSF CMMI process template và xem lại các available work item types,hãy xem tại http://www.microsoft.com/downloads/details.aspx?FamilyID=12A8D806-BB98-4EB4-BF6B-FB5B266171EB&displaylang=en

Để download MSF Agile process template và xem lại available work item types, hãy đến http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F-48FB-824E-828BF593C34D&displaylang=en

Chapter 11 - Project Management Explained

Nguyễn Thị Như Quỳnh — Tue, 20 Oct 2009 11:41:14 GMT
Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 10/20/2009 7:41:14 PM

Chapter 11 - Project Management Explained

Objectives
Chủ đề

Tìm hiểu các chức năng mà Microsoft® Visual Studio® Team System (VSTS) cung cấp cho các nhà quản lý dự án project managers.

Chọn một chiến thuật tạo dự án nhóm team project creation.

Tạo và quản lý các project với Visual Studio Team System.

Overview
Xem trước

Chương này giới thiệu với bạn về các chức năng quản lý dự án (project management features) do Visual Studio Team System cung cấp và chúng giúp bạn vượt qua các vấn đề thông thường và các thử thách liên quan đến việc quản lý các dự án phát triển phần mềm như thế nào(managing software development projects).

Visual Studio Team System và Team Foundation Server (TFS) cung cấp các tool, các template và các report để giúp bạn theo dõi và hỗ trợ các quy trình phát triển phần mềm của bạn(software development processes). Cũng như là tạo ra kết quả giao tiếp nhóm dễ dàng hơn, sự khuyến khích nhau giữa các team members được thực hiện có ý thức hơn, các work item như là các nhiệm vụ được phân công và theo dõi dễ dàng hơn, và những số liệu này cho thấy project health và progress được theo dõi dễ dàng hơn.

How to Use This Chapter

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

Sử dụng chương này để tìm hiểu về các chức năng cụ thể của TFS và VSTS có liên quan đến project managers.

Hãy đọc những phần "Project Management Summary" và "Traditional Project Management Issues" để hiểu các vấn đề mà TFS project management tìm cách giải quyết.

Hãy đọc những phần "Strategies for Team Projects" để xác định chiến thuật của bạn cho việc tổ chức và khởi tạo team project .

Sử dụng các phần còn lại để hiểu hơn về các process templates, work items, và các chức năng quản lý dự án khác(other project management features).

Project Management Summary
Tổng kết về Quản Lý Dự Án

Lập kế hoạch cho một project thường gồm một số biến thể của các bước sau:

1. Generating a Khởi tạo một vision statement. Bước này liên quan đến việc tạo ra một cái nhìn về kết quả cuối cùng theo như mong muốn về project của bạn, được chia sẻ bởi tất cả các bên tham gia dự án.

2. Generating scenarios Tạo ra các kịch bản. Bước này bao gồm việc xác định các thiết lập ban đầu của việc sử dụng các tình huống cho phần mềm. Điều này liên quan đến việc sử dụng các input của khách hàng. Nó cũng liên quan đến việc hợp lí hóa các tình huống để chắc là chúng chính là những giá trị mà khách hàng muốn.

3. Generating set of features to support those scenarios Tạo ra một tập các chức năng để hỗ trợ những kịch bản này. Bước này gồm sự phân chia phá vỡ(breaking) các kịch bản tình huống thành các item cụ thể của các value của khách hàng của bạn, để bạn có thể nói với các khách hàng về sự mong đợi của họ về các item này.

4. Generating a set of Tạo một tập các work itemsitem. Bước này bao gồm việc phân chia(breaking) các tình huống kịch bản và các chức năng thành các nhiệm vụ cụ thể. Đặt một cách khác, khi các work item được hoàn thành, các tính năng hay kịch bản có liên quan sẽ được thực thi.

5. Breaking tasks into areas Phân chia các task thành các area. Còn bước này bao gồm việc breaking các task vào các area. Những area này có thể là các functional(hữu dụng) hoặc căn cứ vào bằng cách nào các team cụ thể được tổ chức.

6. Scheduling the work Lên kế hoạch cho công việc. Bước này có thể bao gồm lên kế hoạch tất cả các công việc trước, hay breaking work phân chia các công việc vào các iteration

Traditional .

Những vấn đề bổ sung về Quản Lý Dự Án Project ManagementIssues

Hầu hết các project managers ngày nay sử dụng nhiều tool khác nhau để quản lý các quy trình phát triển phần mềm(software development process) và các tool này thường có ít nếu có tích hợp với các tool được sử dụng bởi các nhà phát triển phần mềm để thực hiện công việc của họ. Điều này làm thiếu đi sự tích hợp và gắn kết giữa các tool và các team dẫn đến các thách thức lớn cho project manager. Bao gồm các vấn đề tiêu biểu:

Dealing with disparate information sources

Bị chia rẻ với các nguồn thông tin riêng lẻ. Project management tools(CCác tool để quản lý dự án) án thường được sử dụng riêng lẻ, dẫn đến các thông tin mã nguồn bị tách riêng mà không dễ gì có thể hợp nhất được. Ngoài ra, thường rất khó để hợp nhất dữ liệu được duy trì bởi các project management tools tool để quản lý dự án với dữ liệu được duy trì bởi các thành viên nhóm khác như là các lỗi bug được theo dõi với một hệ thống theo dõi bug riêng biệt, để tạo ra các số liệu có ý nghĩa.

Difficultly capturing project-related metrics

Rất khó để thu thập các số liệu liên quan đến dự án. Thu thập các số liệu liên quan đến dự án là rất quan trọng để theo dõi tình trạng, tạo ra các quyết định đầy đủ và trả lời các câu hỏi hữu ích như là "Dự án sẽ được giao vào thời gian nào và ngân sách ra sao?" Để trả lời những câu hỏi chủ chốt này, các project manager thường dựa trên dữ liệu thu được từ Microsoft Office Project hay hệ thống theo dõi bug(bug-tracking system) được sử dụng bởi các nhóm phát triển và kiểm thử. Củng cố các dữ liệu từ các system khác hẳn nhau thì rất khó, tốn thời gian và dễ bị lỗi. Hầu hết các số liệu được tạo ra bởi các tool không được lưu trữ hay truy cập trong một phong cách thống nhất. Tạo ra các report thường là một nỗ lực hướng dẫn chuyên sâu yêu cầu nhiều copy và paste thông tin giữa các tool khác nhau.

Difficultly ensuring that requirements are met(

Rất khó để bảo đảm là các yêu cầu đòi hỏi được đáp ứng)ứng. Thường có một kẻ hở giữa các công việc dự tính cho các development team và các yêu cầu của khách hàng và key non-functional yêu cầu xác định cho system của bạn. Có một kẻ hở khác giữa các scheduled work và actual work. Thông tin quan trọng thường bị mất tại các kẻ hở này và các kết quả yêu cầu không được đáp ứng .

Managing processes and process changes

Quản lý các quy trình và các quá trình thay đổi. Trao đổi giao tiếp giữa các quy trình mà nhóm của bạn làm theo có thể là một nhiệm vụ đầy thử thách. Thực thi các thay đổi để nhắm đến các vấn đề hệ thống mà không ảnh hưởng đến hiệu suất đội có thể thực hiện được ngay cả khi nó thực sự khó khăn hơn.

Lack of auditable communication and

Thiếu sự theo dõi các sự giao tiếp có thể kiểm tra được và các tasktracking. Hợp tác và gắn kết nhóm là những điều hướng đến thông thường bằng cách tổ chức các cuộc họp nhóm và bằng cách lên danh sách phân công công việc cho các lập trình viên để giúp họ tập trung vào các quyền ưu tiên hơn. Theo dõi quy trình các nhiệm vụ cá nhân có thể được thử thách. Ngoài ra, project managers thường tốn nhiều thời gian có giá trị để thu nhặt các tình trạng thông tin từ các kế hoạch và các danh sách khác nhau. Team members cũng tốn nhiều thời gian để hoàn thành các status report và update các loại documents và forms khác nhau.

Quality assurance

Bảo đàm chất lượng. Dự đoán số lượng và mức độ nghiêm trọng của các lỗi(bugs) trong phần mềm mà bạn đang tạo ra thật khó khăn do đó, việc dự đoán tiến độ thực hiện và chi phí thông thường là cách tốt nhất. Như trước kia,những con số sẽ được tính vào các phép đo ngẫu nhiên, các con số này lại phụ thuộc vào quan điểm của người quản lý dự án về tính khả thi của nó.

VSTS được thiết kế để giúp nhiều vấn đề mà các project manager lâu nay thường gặp. Ngoài ra nó còn cung cấp một tập các tool tích hợp để giúp các team cải thiện các hoạt động phát triển phần mềm của họ và giúp các project manager hỗ trợ các quy trình phát triển phần mềm tốt hơn.

Chi tiết về chương này, bạn có thể download tại đây:

Download chương 11

Chapter 11 - Project Management Explained

Nguyễn Thị Như Quỳnh — Mon, 19 Oct 2009 13:29:07 GMT
Revision 1 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 10/19/2009 9:29:07 PM

Objectives

Tìm hiểu các chức năng mà Microsoft® Visual Studio® Team System (VSTS) cung cấp cho các nhà quản lý dự án project managers.

Chọn một chiến thuật tạo dự án nhóm team project creation.

Tạo và quản lý các project với Visual Studio Team System.

Overview

Chương này giới thiệu với bạn về các chức năng quản lý dự án (project management features) do Visual Studio Team System cung cấp và chúng giúp bạn vượt qua các vấn đề thông thường và các thử thách liên quan đến việc quản lý các dự án phát triển phần mềm như thế nào(managing software development projects).

Visual Studio Team System và Team Foundation Server (TFS) cung cấp các tool, các template và các report để giúp bạn theo dõi và hỗ trợ các quy trình phát triển phần mềm của bạn(software development processes). Cũng như là tạo ra kết quả giao tiếp nhóm dễ dàng hơn, sự khuyến khích nhau giữa các team members được thực hiện có ý thức hơn, các work item như là các nhiệm vụ được phân công và theo dõi dễ dàng hơn, và những số liệu này cho thấy project health và progress được theo dõi dễ dàng hơn.

How to Use This Chapter

Sử dụng chương này để tìm hiểu về các chức năng cụ thể của TFS và VSTS có liên quan đến project managers.

Hãy đọc những phần "Project Management Summary" và "Traditional Project Management Issues" để hiểu các vấn đề mà TFS project management tìm cách giải quyết.

Hãy đọc những phần "Strategies for Team Projects" để xác định chiến thuật của bạn cho việc tổ chức và khởi tạo team project .

Sử dụng các phần còn lại để hiểu hơn về các process templates, work items, và các chức năng quản lý dự án khác(other project management features).

Project Management Summary

Lập kế hoạch cho một project thường gồm một số biến thể của các bước sau:

1. Generating a vision statement. Bước này liên quan đến việc tạo ra một cái nhìn về kết quả cuối cùng theo như mong muốn về project của bạn, được chia sẻ bởi tất cả các bên tham gia dự án.

2. Generating scenarios. Bước này bao gồm việc xác định các thiết lập ban đầu của việc sử dụng các tình huống cho phần mềm. Điều này liên quan đến việc sử dụng các input của khách hàng. Nó cũng liên quan đến việc hợp lí hóa các tình huống để chắc là chúng chính là những giá trị mà khách hàng muốn.

3. Generating set of features to support those scenarios. Bước này gồm sự phân chia phá vỡ(breaking) các kịch bản tình huống thành các item cụ thể của các value của khách hàng của bạn, để bạn có thể nói với các khách hàng về sự mong đợi của họ về các item này.

4. Generating a set of work items. Bước này bao gồm việc phân chia(breaking) các tình huống kịch bản và các chức năng thành các nhiệm vụ cụ thể. Đặt một cách khác, khi các work item được hoàn thành, các tính năng hay kịch bản có liên quan sẽ được thực thi.

5. Breaking tasks into areas. Còn bước này bao gồm việc breaking các task vào các area. Những area này có thể là các functional(hữu dụng) hoặc căn cứ vào bằng cách nào các team cụ thể được tổ chức.

6. Scheduling the work. Bước này có thể bao gồm lên kế hoạch tất cả các công việc trước, hay breaking work vào các iteration

Traditional Project Management Issues

Hầu hết các project managers ngày nay sử dụng nhiều tool khác nhau để quản lý các quy trình phát triển phần mềm(software development process) và các tool này thường có ít nếu có tích hợp với các tool được sử dụng bởi các nhà phát triển phần mềm để thực hiện công việc của họ. Điều này làm thiếu đi sự tích hợp và gắn kết giữa các tool và các team dẫn đến các thách thức lớn cho project manager. Bao gồm các vấn đề tiêu biểu:

Dealing with disparate information sources. Project management tools(Các tool để quản lý dự án) thường được sử dụng riêng lẻ, dẫn đến các thông tin mã nguồn riêng mà không dễ gì có thể hợp nhất được. Ngoài ra, thường rất khó để hợp nhất dữ liệu được duy trì bởi các project management tools với dữ liệu được duy trì bởi các thành viên nhóm khác như là các lỗi bug được theo dõi với một hệ thống theo dõi bug riêng biệt, để tạo ra các số liệu có ý nghĩa.

Difficultly capturing project-related metrics. Thu thập các số liệu liên quan đến dự án là rất quan trọng để theo dõi tình trạng, tạo ra các quyết định đầy đủ và trả lời các câu hỏi hữu ích như là "Dự án sẽ được giao vào thời gian nào và ngân sách ra sao?" Để trả lời những câu hỏi chủ chốt này, các project manager thường dựa trên dữ liệu thu được từ Microsoft Office Project hay hệ thống theo dõi bug(bug-tracking system) được sử dụng bởi các nhóm phát triển và kiểm thử. Củng cố các dữ liệu từ các system khác hẳn nhau thì rất khó, tốn thời gian và dễ bị lỗi. Hầu hết các số liệu được tạo ra bởi các tool không được lưu trữ hay truy cập trong một phong cách thống nhất. Tạo ra các report thường là một nỗ lực hướng dẫn chuyên sâu yêu cầu nhiều copy và paste thông tin giữa các tool khác nhau.

Difficultly ensuring that requirements are met(Rất khó để bảo đảm là các yêu cầu đòi hỏi được đáp ứng). Thường có một kẻ hở giữa các công việc dự tính cho các development team và các yêu cầu của khách hàng và key non-functional yêu cầu xác định cho system của bạn. Có một kẻ hở khác giữa các scheduled work và actual work. Thông tin quan trọng thường bị mất tại các kẻ hở này và các kết quả yêu cầu không được đáp ứng .

Managing processes and process changes. Trao đổi giao tiếp giữa các quy trình mà nhóm của bạn làm theo có thể là một nhiệm vụ đầy thử thách. Thực thi các thay đổi để nhắm đến các vấn đề hệ thống mà không ảnh hưởng đến hiệu suất đội có thể thực hiện được ngay cả khi nó thực sự khó khăn hơn.

Lack of auditable communication and task tracking. Hợp tác và gắn kết nhóm là những điều hướng đến thông thường bằng cách tổ chức các cuộc họp nhóm và bằng cách lên danh sách phân công công việc cho các lập trình viên để giúp họ tập trung vào các quyền ưu tiên hơn. Theo dõi quy trình các nhiệm vụ cá nhân có thể được thử thách. Ngoài ra, project managers thường tốn nhiều thời gian có giá trị để thu nhặt các tình trạng thông tin từ các kế hoạch và các danh sách khác nhau. Team members cũng tốn nhiều thời gian để hoàn thành các status report và update các loại documents và forms khác nhau.

Quality assurance. Dự đoán số lượng và mức độ nghiêm trọng của các lỗi(bugs) trong phần mềm mà bạn đang tạo ra thật khó khăn do đó, việc dự đoán tiến độ thực hiện và chi phí thông thường là cách tốt nhất. Như trước kia,những con số sẽ được tính vào các phép đo ngẫu nhiên, các con số này lại phụ thuộc vào quan điểm của người quản lý dự án về tính khả thi của nó.

VSTS được thiết kế để giúp nhiều vấn đề mà các project manager lâu nay thường gặp. Ngoài ra nó còn cung cấp một tập các tool tích hợp để giúp các team cải thiện các hoạt động phát triển phần mềm của họ và giúp các project manager hỗ trợ các quy trình phát triển phần mềm tốt hơn.

Chi tiết về chương này, bạn có thể download tại đây:

Download chương 11

Chapter 12 - Work Items Explained

Nguyễn Thị Như Quỳnh — Tue, 20 Oct 2009 00:38:06 GMT
Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 10/20/2009 8:38:06 AM

Chapter 12 - Work Items Explained

Chủ đề

Tìm hiểu về cấu trúc và mục đích của các work items.

Mô tả work item workflow.

Tùy chỉnh các work item để đáp ứng những nhu cầu cụ thể của nhóm của bạn.

Xem trước

Chương này giới thiệu cho bạn về các work item và giải thích bằng cách nào bạn có thể sử dụng chúng để giúp quản lí các dự án phát triển phần mềm của bạn. Mỗi work item đại diện cho một đơn vị công việc(unit of work) được thực hiện bởi nhóm phát triển của bạn. Một tập các loại work item type được định nghĩa trong process template mà bạn chọn khi tạo mới một team project.

Sau khi project của bạn được khởi động, bạn có thể tạo bất kì loại work item type có sẵn nào để theo dõi những tiến độ làm việc. Trong khi các loại work item type mặc định và cách xử lý(behaviour) được định nghĩa trong các process templates, bất kì khía cạnh nào của work item type đều có thể được chỉnh sửa để phù hợp hơn với phương pháp làm việc của nhóm bạn.

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

Để đạt được những lợi ích tốt nhất từ chương này, bạn nên:

Đọc phần "Work Item Structure" để tìm hiểu về các work item types đã được xác định trước và các work item workflow được định nghĩa như thế nào.

Đọc phần "Customizing Work Items" để tìm hiểu làm thế nào và tại sao bạn nên tùy chỉnh work item type.

Scenarios và Solutions

Các work item là những phương pháp chính mà các project manager và các team leader theo dõi công việc, là những việc còn lại cần được thực hiện trên một project, cũng như công việc đã được hoàn thành. Các team member sử dụng các work item để theo dõi công việc cá nhân của họ và phân công công việc đến các thành viên khác ví dụ, trong dạng lỗi hay các nhiệm vụ.

Sau đây là các cách sử dụng các work item chung trong các team project:

Tạo các user requirement hay Quality of Service (QoS) requirements cho một ứng dụng.

Theo dõi phát triển và kiểm thử đối với các requirement.

Tạo các development task để đại diện cho công việc cần được hoàn thành để thực thi các thành phần và chức năng của ứng dụng.

Tạo các bug để đại diện cho các khuyết tật(defect) trong khi thực thi các thành phần và chức năng của ứng dụng.

Phân loại bug(lỗi) và task(nhiệm vụ) để họ được ưu tiên(prioritized) và cân bằng(balanced) một các tương thích trên toàn đội.

Theo dõi các development task để xác định những hướng tiến bộ về tình trạng hoàn thiện code (code complete status).

Theo dõi các bug, cùng với các số liệu chất lượng khác, để xác định chất lượng của ứng dụng và sự sẵn sàng của nó để được di chuyển.

Bạn sẽ sử dụng các work item dựa trên các loại work item type được định nghĩa cho project của bạn như thế nào. Sự định nghĩa các work item được lưu trữ trong process template mà bạn đã chọn khi tạo team project của bạn lần đầu tiên. Bạn có thể chọn một trong hai templates mặc định- Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) hay MSF for CMMI® Process Improvement (MSF CMMI) - hay bạn có thể tùy chỉnh các work item để đáp ứng cho các nhu cầu và các quy trình cụ thể của nhóm bạn.

Cấu trúc Work Item

Mỗi work item type có thể được định nghĩa như sau:

•

Nó có một mục đích và ý định sử dụng. Đối với trường hợpVí dụ, các bug(lỗi) được sử dụng để theo dõi chất lượng các defect(khuyết tật), các task được sử dụng để theo dõi các scheduled work, QoS requirements được sử dụng để nắm bắt các khía cạnh phi chức năng non-functional quan trọng như là bảo mật( security) và thực thi các yêu cầu(performance requirement), và vv...

Nó có một workflow(tiến trình công việc) được định nghĩa bởi các state và transition. Thí dụ, giai đoạn từ "Opened" đến "Resolved" đến trạng thái "Closed".

Nó có một tập các field mà có thể được cài đặt, truy vấn, và báo cáo. Thí dụ, Priority, Status và, Iteration.

Các loại Work Item

The MSF Agile và MSF CMMI process templates mỗi loại định nghĩa một tập các work item mà ánh xạ(map) đến các roles và activities được định nghĩa trong process guidance.

Loại MSF Agile Work Item

MSF Agile chứa các work item type sau:

Bug. Đại diện một problem vấn đề hay potential problem là vấn đề tiềm tàng trong ứng dụng của bạn.

Risk. Đại diện một event hay điều kiện có thể mà có tác động tiêu cực đến project dự án của bạn.

Scenario. Đại diện một đường dẫn duy nhất của sự tương tác của user thông qua hệ thống.

Task. Đại diện nhu cầu cho một thành viên của nhóm để làm một số các công việc.

Quality of Service Requirement. Đại diện một yêu cầu(requirement) cầu ràng buộc mà cho biết là hệ thống nên làm việc như thế nào.

Loại MSF CMMI Work Item

MSF CMMI contains the following chứa các loại work item typessau:

Bug. Đại diện một problem vấn đề hay potential problem là vấn đề tiềm tàng trong ứng dụng của bạn.

Change Request. Đại diện cho một thay đổi được đề nghị đến ứng dụng của bạn.

Issue. Đại diện cho một tình huống mà block công việc bị tắc nghẽn hay hiện tại là blocking workthời công việc đang bị tắc nghẻn.

Requirement. Đại diện một sự miêu tả vè về những gì mà ứng dụng của bạn nên làm để giải quyết một customer problem. vấn đề của khách hàng.

Review. Đại diện các kết quả của một sự xem lại code, design(thiết kế), hay deployment(sự triển khai).

Risk. Đại diện một event hay điều kiện có thể mà có tác động tiêu cực đến project của bạn

Task. Đại diện cho những như yêu cầu của cho một thành viên của nhóm để thực hiện một số việc.

Để có thêm chi tiết về chương này, bạn có thể download tại đây:

Download chương 12

Chapter 12 - Work Items Explained

Nguyễn Thị Như Quỳnh — Tue, 20 Oct 2009 00:25:00 GMT
Revision 1 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 10/20/2009 8:25:00 AM

Chủ đề

Tìm hiểu về cấu trúc và mục đích của các work items.

Mô tả work item workflow.

Tùy chỉnh các work item để đáp ứng những nhu cầu cụ thể của nhóm của bạn.

Xem trước

Chương này giới thiệu cho bạn về các work item và giải thích bằng cách nào bạn có thể sử dụng chúng để giúp quản lí các dự án phát triển phần mềm của bạn. Mỗi work item đại diện cho một đơn vị công việc(unit of work) được thực hiện bởi nhóm phát triển của bạn. Một tập các loại work item type được định nghĩa trong process template mà bạn chọn khi tạo mới một team project.

Sau khi project của bạn được khởi động, bạn có thể tạo bất kì loại work item type có sẵn nào để theo dõi những tiến độ làm việc. Trong khi các loại work item type mặc định và cách xử lý(behaviour) được định nghĩa trong các process templates, bất kì khía cạnh nào của work item type đều có thể được chỉnh sửa để phù hợp hơn với phương pháp làm việc của nhóm bạn.

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

Để đạt được những lợi ích tốt nhất từ chương này, bạn nên:

Đọc phần "Work Item Structure" để tìm hiểu về các work item types đã được xác định trước và các work item workflow được định nghĩa như thế nào.

Đọc phần "Customizing Work Items" để tìm hiểu làm thế nào và tại sao bạn nên tùy chỉnh work item type.

Scenarios và Solutions

Các work item là những phương pháp chính mà các project manager và các team leader theo dõi công việc, là những việc còn lại cần được thực hiện trên một project, cũng như công việc đã được hoàn thành. Các team member sử dụng các work item để theo dõi công việc cá nhân của họ và phân công công việc đến các thành viên khác ví dụ, trong dạng lỗi hay các nhiệm vụ.

Sau đây là các cách sử dụng các work item chung trong các team project:

Tạo các user requirement hay Quality of Service (QoS) requirements cho một ứng dụng.

Theo dõi phát triển và kiểm thử đối với các requirement.

Tạo các development task để đại diện cho công việc cần được hoàn thành để thực thi các thành phần và chức năng của ứng dụng.

Tạo các bug để đại diện cho các khuyết tật(defect) trong khi thực thi các thành phần và chức năng của ứng dụng.

Phân loại bug(lỗi) và task(nhiệm vụ) để họ được ưu tiên(prioritized) và cân bằng(balanced) một các tương thích trên toàn đội.

Theo dõi các development task để xác định những hướng tiến bộ về tình trạng hoàn thiện code (code complete status).

Theo dõi các bug, cùng với các số liệu chất lượng khác, để xác định chất lượng của ứng dụng và sự sẵn sàng của nó để được di chuyển.

Bạn sẽ sử dụng các work item dựa trên các work item type được định nghĩa cho project của bạn như thế nào. Sự định nghĩa các work item được lưu trữ trong process template mà bạn đã chọn khi tạo team project của bạn lần đầu tiên. Bạn có thể chọn một trong hai templates mặc định- Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) hay MSF for CMMI® Process Improvement (MSF CMMI) - hay bạn có thể tùy chỉnh các work item để đáp ứng cho các nhu cầu và các quy trình cụ thể của nhóm bạn.

Cấu trúc Work Item

Mỗi work item type có thể được định nghĩa như sau:

• Nó có một mục đích và ý định sử dụng. Đối với trường hợp, các bug(lỗi) được sử dụng để theo dõi chất lượng các defect(khuyết tật), các task được sử dụng để theo dõi các scheduled work, QoS requirements được sử dụng để nắm bắt các khía cạnh non-functional quan trọng như là bảo mật( security) và thực thi các yêu cầu(performance requirement), và vv...

Nó có một workflow(tiến trình công việc) được định nghĩa bởi các state và transition. Thí dụ, giai đoạn từ "Opened" đến "Resolved" đến trạng thái "Closed".

Nó có một tập các field mà có thể được cài đặt, truy vấn, và báo cáo. Thí dụ, Priority, Status và, Iteration.

Các loại Work Item

The MSF Agile và MSF CMMI process templates mỗi loại định nghĩa một tập các work item mà ánh xạ(map) đến các roles và activities được định nghĩa trong process guidance.

Loại MSF Agile Work Item

MSF Agile chứa các work item type sau:

Bug. Đại diện một problem hay potential problem trong ứng dụng của bạn.

Risk. Đại diện một event hay điều kiện có thể mà có tác động tiêu cực đến project của bạn.

Scenario. Đại diện một đường dẫn duy nhất của sự tương tác của user thông qua hệ thống.

Task. Đại diện nhu cầu cho một thành viên của nhóm để làm một số các công việc.

Quality of Service Requirement. Đại diện một yêu cầu(requirement) ràng buộc mà hệ thống nên làm việc như thế nào.

Loại MSF CMMI Work Item

MSF CMMI contains the following work item types:

Bug. Đại diện một problem hay potential problem trong ứng dụng của bạn.

Change Request. Đại diện cho một thay đổi được đề nghị đến ứng dụng của bạn.

Issue. Đại diện cho một tình huống mà block công việc hay hiện tại là blocking work.

Requirement. Đại diện một sự miêu tả vè những gì mà ứng dụng của bạn nên làm để giải quyết một customer problem.

Review. Đại diện các kết quả của một sự xem lại code, design(thiết kế), hay deployment(sự triển khai).

Risk. Đại diện một event hay điều kiện có thể mà có tác động tiêu cực đến project của bạn

Task. Đại diện cho những như cầu của một thành viên của nhóm để thực hiện một số việc.

Để có thêm chi tiết về chương này, bạn có thể download tại đây:

Download chương 12

Chapter 10 - Large Project Considerations

Nguyễn Thị Như Quỳnh — Mon, 19 Oct 2009 10:46:37 GMT
Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 10/19/2009 6:46:37 PM

Chủ đề

Tìm hiểu các tiến trình công việc workflow của các dự án lớn trong Microsoft® Visual Studio® Team System Team Foundation Server (TFS).

Tìm hiểu bằng cách nào để tối ưu hóasource control và các build cho các nhóm phát triển lớn.

Tìm hiểu source control bị tác động bởi các dự án lớn như thế nào.

Tìm hiểu các chiến lược branching và merging (phân nhánh và hợp nhất ) của bạn có thể cần phải thay đổi như thế nào nếu bạn đang tham gia vào một dự án lớn.

Tìm hiểu các chiến lược build bị ảnh hưởng bởi các dự án lớn như thế nào.

Xem trước

Chương này mô tả các cân nhắc bổ sung thêm đối với các nỗ lực phát triển quy mô lớn với TFS. Một dự án lớn điển hình khác với một dự án nhỏ hơn chúng ta có thể nhận biết theo các cách sau:

Dự án lớn yêu cầu một cấu trúc branching và merging phức tạp hơn.

Dự án lớn phải đối phó với số các sự phụ thuộc giữa các solution và các dự án nhóm lớn hơn.

Dự án lớn có khả năng bảo trì các build nhiều hơn cho các thành phần và các nhóm.

Thí dụ, trong một dự án lớn bạn có thể cần hỗ trợ nhiều phân nhánh branch để hỗ trợ các nỗ lực phát triển song song của các nhóm chức năng khác nhau. Trong tình huống này, bạn có khả năng cần để quản lý các sự phụ thuộc giữa các solutions và các dự án nhóm và để share các Web services và databases thông thường. Mỗi sub-team có lẽ cần được duy trì các build server và các output builds của riêng nó để xác định một drop point cụ thể.

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

Sử dụng chương này nếu bạn cần để quản lý, hỗ trợ hay tham gia các dự án phát triển quy mô lớn(large-scale development project). Chương 3, 5, và 7 cũng cung cấp các phần "Large Project Considerations" xác định. Sử dụng chương này để xem lại tất cả các sự cân nhắc thêm cho các dự án (large project consideration) trong một single place.

Chi tiết chương 10, các bạn có thể tải ở đây:

Download Chương 10

Chapter 9 - Setting Up Scheduled Builds with Team Build

Nguyễn Thị Như Quỳnh — Wed, 23 Sep 2009 15:16:05 GMT
Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/23/2009 11:16:05 PM

Chapter 9 - Setting Up Scheduled Builds with Team Build

Objectives

Hiểu được mục đích của một scheduled build.

Thiết lập một scheduled build với Microsoft® Visual Studio® Team System Team Build.

Overview

Chương này sẽ giải thích bằng cách nào bạn có thể thiết lập scheduled builds bằng cách sử dụng Team Build và Microsoft Visual Studio Team Foundation Server (TFS). Mục đích của một scheduled build là tự động hóa quy trình khởi tạo một reliable build trên một consistent schedule. Đây là một kiểu build mà hầu như được sử dụng bởi các test team, internal adopters, và external beta users.

Scheduled builds là một dạng đơn giản nhất của build automation. Bạn có thể cấu hình scheduled builds để chạy hàng giờ, hàng ngày, hàng tuần, hay bất cứ khoảng thời gian nào mà đội của bạn thực hiện công việc tốt nhất.

How to Use This Chapter

Sử dụng chương này để học các chiến lược cho các scheduled build và để tìm hiểu bằng cách nào để thiết lập và cấu hình các scheduled builds bằng cách sử dụng Team Build. Việc trình bày qua từng bước để giúp bạn thiết lập một scheduled build hãy xem, "How To: Set Up a Scheduled Build."

Nếu bạn cảm thấy lạ lẫm đối với TFS và Team Build, hay nếu bạn muốn học nhiều hơn về các tùy chọn có sẵn đối với automating và các scheduling build, hãy đọc "Chapter 7 - Team Build Explained" trước khi đọc chương này.

Nếu bạn quan tâm về các build instability(các build không ổn định) do chất lượng của code mà development team của bạn checks in, bạn nên xem xét sử dụng các continuous integration builds. Để có thêm thông tin về các continuous integration, hãy xem "Chapter 8 - Setting Up Continuous Integration with Team Build."

Strategy for Scheduled Build Frequency

Frequency(Tần số/Mức độ) của các build của bạn là một trong các quyết định quan trọng nhất để thực hiện, khi khởi tạo một scheduled build. Bạn có thể chọn để schedule(lên lịch) các build của bạn dựa trên cơ sở hàng giờ, hàng đêm hay hàng tuần .

Hourly Builds

Nếu bạn đang làm việc trên một project mà có đủ các check-ins gây ra những thay đổi đáng kể trong vòng một giờ, và không sử dụng các continuous integration build bạn có thể chọn một hourly build frequency(theo mức độ build hàng giờ). Các Hourly build để cung cấp một feedback nhanh chóng đến các developers và cũng có thể được làm sẵn đế cho các testers và các thành viên của nhóm khác thu hút được các feedback(phản hồi) của họ.

Nightly Builds

Đây là scheduled build frequency thông thường nhất vì nó đưa cho các test và các development team của bạn một build mới mỗi buổi sáng kết hợp với các thay đổi khác từ các ngày trước, sẵn sàng để được test.

Weekly Builds

Nếu bạn đang làm việc trên một project lớn và phức tạp, nơi mà các build time có thể last for days, bạn nên lựa chọn các weekly build. Điều này đảm bảo cho test team của bạn có một build khi bắt đầu mỗi week kết hợp các thay đổi của các tuần trước đó, sẵn sàng để test.

Scheduled Build in Team Foundation Server

Các chức năng Team Build feature trong TFS không hỗ trợ các scheduled builds từ các giao diện người dùng(user interface). Thay vào đó, bạn có thể sử dụng Microsoft Windows® Task Scheduler để run các TFSBuild command utility để khởi động các build tại một thời điểm đã định trước.

Sử dụng các bước sau để khởi tạo một scheduled build:

1. Tạo một TFSBuild command line.

TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>

2. Thay thế command line trong một batch file. Lưu ý là bạn phải xác định full path đến TFSBuild.exe file để nó có thể run từ windows command prompt. Một thí dụ của command được sử dụng trong một batch file giống như sau:

"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TFSBuild" start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>

3. Tạo một Windows Scheduled Task mà run batch file tại khoảng thời gian mong muốn của bạn.

Để có thêm thông tin hãy xem "How To: Set Up a Scheduled Build in Visual Studio Team Foundation Server."

Summary

Sử dụng một scheduled build để tạo ra các consistent builds mà bạn có thể đưa cho test team của bạn hay các build consumer khác, những người có thể cung cấp các feedback về chất lượng của các build. Team Foundation Server không hỗ trợ scheduled builds từ user interface của nó. Thay vào đó bạn có thể sử dụng Windows Task Scheduler để chạy TFSBuild command utility để khởi động các build của bạn tại một thời điểm được định trước.

Bạn có thể cấu hình các scheduled build của bạn để chạy hourly(hàng giờ), daily(hàng ngày), weekly(hàng tuần), hay bất cứ khoảng thời gian nào phù hợp với các yêu cầu của project của bạn.

Additional Resources

Để có thêm thông tin về thiết lập một scheduled build hãy xem, "How To - Configure a Scheduled Build (Command Line)" tại đây: http://msdn2.microsoft.com/en-us/library/ms181727(VS.80).aspx

Bạn có thể download tài liệu tại đây: Chapter 9

Chapter 9 - Setting Up Scheduled Builds with Team Build

Nguyễn Thị Như Quỳnh — Wed, 23 Sep 2009 15:13:32 GMT
Revision 2 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/23/2009 11:13:32 PM

Chapter 9 - Setting Up Scheduled Builds with Team Build

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="ProgId" content="Word.Document" /> <meta name="Generator" content="Microsoft Word 12" /> <meta name="Originator" content="Microsoft Word 12" /> <link rel="File-List" href="file:///C:\Users\kpopyo\AppData\Local\Temp\msohtmlclip1\01\clip_filelist.xml" />  <link rel="themeData" href="file:///C:\Users\kpopyo\AppData\Local\Temp\msohtmlclip1\01\clip_themedata.thmx" /> <link rel="colorSchemeMapping" href="file:///C:\Users\kpopyo\AppData\Local\Temp\msohtmlclip1\01\clip_colorschememapping.xml" />  <style></style>  
Objectives<o:p></o:p>

•

Hiểu được mục đích của một scheduled build. <o:p></o:p>

•

Thiết lập một scheduled build với Microsoft® Visual Studio® Team System Team Build.<o:p></o:p>

Overview<o:p></o:p>

Chương này sẽ giải thích bằng cách nào bạn có thể thiết lập scheduled builds bằng cách sử dụng Team Build và Microsoft Visual Studio Team Foundation Server (TFS). Mục đích của một scheduled build là tự động hóa quy trình khởi tạo một reliable build trên một consistent schedule. Đây là một kiểu build mà hầu như được sử dụng bởi các test team, internal adopters, và external beta users. <o:p></o:p>

Scheduled builds là một dạng đơn giản nhất của build automation. Bạn có thể cấu hình scheduled builds để chạy hàng giờ, hàng ngày, hàng tuần, hay bất cứ khoảng thời gian nào mà đội của bạn thực hiện công việc tốt nhất.<o:p></o:p>

How to Use This Chapter<o:p></o:p>

Sử dụng chương này để học các chiến lược cho các scheduled build và để tìm hiểu bằng cách nào để thiết lập và cấu hình các scheduled builds bằng cách sử dụng Team Build. Việc trình bày qua từng bước để giúp bạn thiết lập một scheduled build hãy xem, “How "How To: Set Up a Scheduled Build.”   <o:p></o:p>"

Nếu bạn cảm thấy lạ lẫm đối với TFS và Team Build, hay nếu bạn muốn học nhiều hơn về các tùy chọn có sẵn đối với automating và các scheduling build, hãy đọc “Chapter "Chapter 7 - Team Build Explained” " trước khi đọc chương này.<o:p></o:p>

<o:p></o:p>ày.

Nếu bạn quan tâm về các build instability(các build không ổn định) do chất lượng của code mà development team của bạn checks in, bạn nên xem xét sử dụng các continuous integration builds. Để có thêm thông tin về các continuous integration, hãy xem “Chapter "Chapter 8 - Setting Up Continuous Integration with Team Build.”<o:p></o:p>"

Strategy for Scheduled Build Frequency<o:p></o:p>

Frequency(Tần số/Mức độ) của các build của bạn là một trong các quyết định quan trọng nhất để thực hiện, khi khởi tạo một scheduled build. Bạn có thể chọn để schedule(lên lịch) các build của bạn dựa trên cơ sở hàng giờ, hàng đêm hay hàng tuần .<o:p></o:p>

Hourly Builds<o:p></o:p>

Nếu bạn đang làm việc trên một project mà có đủ các check-ins gây ra những thay đổi đáng kể trong vòng một giờ, và khôngông sử dụng các continuous integration build bạn có thể chọn một hourly build frequency(theo mức độ build hàng giờ). Các Hourly build để cung cấp một feedback nhanh chóng đến các developers và cũng có thể được làm sẵn đế cho các testers và các thành viên của nhóm khác thu hút được các feedback(phản hồi) của họ.<o:p></o:p>

Nightly Builds <o:p></o:p>

Đây là scheduled build frequency thông thường nhất vì nó đưa cho các test và các development team của bạn một build mới mỗi buổi sáng kết hợp với các thay đổi khác từ các ngày trước, sẵn sàng để được test.   <o:p></o:p>

Weekly Builds <o:p></o:p>

Nếu bạn đang làm việc trên một project lớn và phức tạp, nơi mà các build time có thể last for days, bạn nên lựa chọn các weekly build. Điều này đảm bảo cho test team của bạn có một build khi bắt đầu mỗi week kết hợp các thay đổi của các tuần trước đó, sẵn sàng để test.    <o:p></o:p>

Scheduled Build in Team Foundation Server <o:p></o:p>

Các chức năng Team Build feature trong TFS không hỗ trợ các scheduled builds từ các giao diện người dùng(user interface). Thay vào đó, bạn có thể sử dụng Microsoft Windows® Task Scheduler để run các TFSBuild command utility để khởi động các build tại một thời điểm đã định trước. <o:p></o:p>

Sử dụng các bước sau để khởi tạo một scheduled build: <o:p></o:p>

1. Tạo một TFSBuild command line. <o:p></o:p>

TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>> <o:p></o:p>

2. Thay thế command line trong một batch file. Lưu ý là bạn phải xác định full path đến TFSBuild.exe file để nó có thể run từ windows command prompt. Một thí dụ của command được sử dụng trong một batch file giống như sau: <o:p></o:p>

"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TFSBuild" start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>> <o:p></o:p>

3. Tạo một Windows Scheduled Task mà run batch file tại khoảng thời gian mong muốn của bạn. <o:p></o:p>

Để có thêm thông tin hãy xem “How "How To: Set Up a Scheduled Build in Visual Studio Team Foundation Server.”<o:p></o:p>"

Summary <o:p></o:p>

Sử dụng một scheduled build để tạo ra các consistent builds mà bạn có thể đưa cho test team của bạn hay các build consumer khác, những người có thể cung cấp các feedback về chất lượng của các build. Team Foundation Server không hỗ trợ scheduled builds từ user interface của nó. Thay vào đó bạn có thể sử dụng Windows Task Scheduler để chạy TFSBuild command utility để khởi động các build của bạn tại một thời điểm được định trước. <o:p></o:p>

Bạn có thể cấu hình các scheduled build của bạn để chạy hourly(hàng giờ), daily(hàng ngày), weekly(hàng tuần), hay bất cứ khoảng thời gian nào phù hợp với các yêu cầu của project của bạn.<o:p></o:p>

Additional Resources <o:p></o:p>

•

Để có thêm thông tin về thiết lập một scheduled build hãy xem, “How "How To – - Configure a Scheduled Build (Command Line)” " tại<o:p></o:p>

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

Bạn có thể download tài liệu tại đây: Chapter 9

Chapter 9 - Setting Up Scheduled Builds with Team Build

Nguyễn Thị Như Quỳnh — Wed, 23 Sep 2009 15:10:42 GMT
Revision 1 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/23/2009 11:10:42 PM

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="ProgId" content="Word.Document" /> <meta name="Generator" content="Microsoft Word 12" /> <meta name="Originator" content="Microsoft Word 12" /> <link rel="File-List" href="file:///C:\Users\kpopyo\AppData\Local\Temp\msohtmlclip1\01\clip_filelist.xml" />  <link rel="themeData" href="file:///C:\Users\kpopyo\AppData\Local\Temp\msohtmlclip1\01\clip_themedata.thmx" /> <link rel="colorSchemeMapping" href="file:///C:\Users\kpopyo\AppData\Local\Temp\msohtmlclip1\01\clip_colorschememapping.xml" />  <style></style>  

Objectives<o:p></o:p>

• Hiểu được mục đích của một scheduled build. <o:p></o:p>

• Thiết lập một scheduled build với Microsoft® Visual Studio® Team System Team Build.<o:p></o:p>

Overview<o:p></o:p>

Chương này sẽ giải thích bằng cách nào bạn có thể thiết lập scheduled builds bằng cách sử dụng Team Build và Microsoft Visual Studio Team Foundation Server (TFS). Mục đích của một scheduled build là tự động hóa quy trình khởi tạo một reliable build trên một consistent schedule. Đây là một kiểu build mà hầu như được sử dụng bởi các test team, internal adopters, và external beta users. <o:p></o:p>

Scheduled builds là một dạng đơn giản nhất của build automation. Bạn có thể cấu hình scheduled builds để chạy hàng giờ, hàng ngày, hàng tuần, hay bất cứ khoảng thời gian nào mà đội của bạn thực hiện công việc tốt nhất.<o:p></o:p>

How to Use This Chapter<o:p></o:p>

Sử dụng chương này để học các chiến lược cho các scheduled build và để tìm hiểu bằng cách nào để thiết lập và cấu hình các scheduled builds bằng cách sử dụng Team Build. Việc trình bày qua từng bước để giúp bạn thiết lập một scheduled build hãy xem, “How To: Set Up a Scheduled Build.”   <o:p></o:p>

Nếu bạn cảm thấy lạ lẫm đối với TFS và Team Build, hay nếu bạn muốn học nhiều hơn về các tùy chọn có sẵn đối với automating và các scheduling build, hãy đọc “Chapter 7 - Team Build Explained” trước khi đọc chương này.<o:p></o:p>

<o:p></o:p>

Nếu bạn quan tâm về các build instability(các build không ổn định) do chất lượng của code mà development team của bạn checks in, bạn nên xem xét sử dụng các continuous integration builds. Để có thêm thông tin về các continuous integration, hãy xem “Chapter 8 - Setting Up Continuous Integration with Team Build.”<o:p></o:p>

Strategy for Scheduled Build Frequency<o:p></o:p>

Frequency(Tần số/Mức độ) của các build của bạn là một trong các quyết định quan trọng nhất để thực hiện, khi khởi tạo một scheduled build. Bạn có thể chọn để schedule(lên lịch) các build của bạn dựa trên cơ sở hàng giờ, hàng đêm hay hàng tuần .<o:p></o:p>

Hourly Builds<o:p></o:p>

Nếu bạn đang làm việc trên một project mà có đủ các check-ins gây ra những thay đổi đáng kể trong vòng một giờ, và không sử dụng các continuous integration build bạn có thể chọn một hourly build frequency(theo mức độ build hàng giờ). Các Hourly build để cung cấp một feedback nhanh chóng đến các developers và cũng có thể được làm sẵn đế cho các testers và các thành viên của nhóm khác thu hút được các feedback(phản hồi) của họ.<o:p></o:p>

Nightly Builds <o:p></o:p>

Đây là scheduled build frequency thông thường nhất vì nó đưa cho các test và các development team của bạn một build mới mỗi buổi sáng kết hợp với các thay đổi khác từ các ngày trước, sẵn sàng để được test.   <o:p></o:p>

Weekly Builds <o:p></o:p>

Nếu bạn đang làm việc trên một project lớn và phức tạp, nơi mà các build time có thể last for days, bạn nên lựa chọn các weekly build. Điều này đảm bảo cho test team của bạn có một build khi bắt đầu mỗi week kết hợp các thay đổi của các tuần trước đó, sẵn sàng để test.    <o:p></o:p>

Scheduled Build in Team Foundation Server <o:p></o:p>

Các chức năng Team Build feature trong TFS không hỗ trợ các scheduled builds từ các giao diện người dùng(user interface). Thay vào đó, bạn có thể sử dụng Microsoft Windows® Task Scheduler để run các TFSBuild command utility để khởi động các build tại một thời điểm đã định trước. <o:p></o:p>

Sử dụng các bước sau để khởi tạo một scheduled build: <o:p></o:p>

1. Tạo một TFSBuild command line. <o:p></o:p>

TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>> <o:p></o:p>

2. Thay thế command line trong một batch file. Lưu ý là bạn phải xác định full path đến TFSBuild.exe file để nó có thể run từ windows command prompt. Một thí dụ của command được sử dụng trong một batch file giống như sau: <o:p></o:p>

"C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TFSBuild" start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>> <o:p></o:p>

3. Tạo một Windows Scheduled Task mà run batch file tại khoảng thời gian mong muốn của bạn. <o:p></o:p>

Để có thêm thông tin hãy xem “How To: Set Up a Scheduled Build in Visual Studio Team Foundation Server.”<o:p></o:p>

Summary <o:p></o:p>

Sử dụng một scheduled build để tạo ra các consistent builds mà bạn có thể đưa cho test team của bạn hay các build consumer khác, những người có thể cung cấp các feedback về chất lượng của các build. Team Foundation Server không hỗ trợ scheduled builds từ user interface của nó. Thay vào đó bạn có thể sử dụng Windows Task Scheduler để chạy TFSBuild command utility để khởi động các build của bạn tại một thời điểm được định trước. <o:p></o:p>

Bạn có thể cấu hình các scheduled build của bạn để chạy hourly(hàng giờ), daily(hàng ngày), weekly(hàng tuần), hay bất cứ khoảng thời gian nào phù hợp với các yêu cầu của project của bạn.<o:p></o:p>

Additional Resources <o:p></o:p>

• Để có thêm thông tin về thiết lập một scheduled build hãy xem, “How To – Configure a Scheduled Build (Command Line)” tại<o:p></o:p>

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

Bạn có thể download tài liệu tại đây: Chapter 9

Chương 7 - Team Build Explained

Nguyễn Thị Như Quỳnh — Fri, 18 Sep 2009 00:41:26 GMT
Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/18/2009 8:41:26 AM

Chương 7 - Team Build Explained

PART III

Builds

In This Part:

Team Build Explained

Setting Up Continuous Integration with Team Build

Setting Up Scheduled Builds with Team Build

Chương 7 - Team Build Explained

Objectives

Tìm hiểu kiến trúc Microsoft® Visual Studio® Team System Team Build .

Tìm hiểu các thành phần tạo nên Team Build.

Tìm hiểu các chức năng của Team Build cung cấp.

Chọn một chiến lược build phù hợp.

Xác định phương pháp mà chiến lược build của bạn có thể cần được thay đổi nếu bạn làm trên một project lớn.

Overview

Chương này giải thích bằng cách nào bạn có thể sử dụng Team Build để tự động hóa quá trình thiết kế(build process). Nó vạch ra một số các sai lầm chung liên quan đến quy trình build (common build-related stumbling blocks) và so sánh các phương pháp tiếp cận khác nhau để builds ranging từ các daily scheduled build đến các continuous integration builds.

Team Build được thiết kế ở đầu của Microsoft Build Engine (MSBuild) và bạn có thể sử dụng nó để lấy các source code cần thiết cho một build, biên dịch các solution và (nếu có yêu cầu) thực thi các kiểm thử đơn vị( unit test) và công cụ phân tích code tĩnh như một phần của quá trình thiết kế(build process). Bạn cũng có thể phát hành các build đầu ra đến một shared location(vị trí chia sẻ) cụ thể.

Team Build labels source code được sử dụng cho một loại build đặc biệt với một số các build để bạn có thể lấy source được sử dụng để khởi tạo một build cụ thể tại một số điểm trong tương lai. Trong trường hợp thất bại, bạn có thể cấu hình Team Build để khởi tạo các work item và để lưu ý cho các người sử dụng về các build failures gặp phải.

How to Use This Chapter

Sử dụng chương này để tìm hiểu về các chức năng mà Team Build cung cấp cho việc tự động hóa và quản lý quá trình build, và để hiểu về các chiến lược khác nhau cho việc lập kế hoạch build. Để đạt được lợi ích cao nhất từ chương này, bạn nên:

§ Đọc "Chapter 8 - Setting up Continuous Integration with Team Build" để tìm hiểu nhiều hơn về việc sử dụng continuous integration với Team Foundation Server (TFS).

§ Đọc "Chapter 9 - Setting up Scheduled Builds with Team Build" để tìm hiểu nhiều hơn về việc sử dụng các scheduled builds.

§ Đọc các đề tài How To kèm theo để giúp thực hiện các nhiệm vụ liên quan đến build:

How To: Tự động Run Code Analysis với Team Build trong Visual Studio Team Foundation Server.

How To: Cài đặt một Continuous Integration Build trong Visual Studio Team Foundation Server.

How To: Cài đặt một Scheduled Build trong Visual Studio Team Foundation Server.

Download tài liệu tại đây: Part III- Chapter 7

Chương 7 - Team Build Explained

Nguyễn Thị Như Quỳnh — Thu, 17 Sep 2009 16:56:43 GMT
Revision 3 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/18/2009 12:56:43 AM

Chương 7 - Team Build Explained

PART III

Builds

In This Part:

Team Build Explained

Setting Up Continuous Integration with Team Build

Setting Up Scheduled Builds with Team Build

Chương 7 - Team Build Explained

Objectives

Tìm hiểu kiến trúc Microsoft® Visual Studio® Team System Team Build .

Tìm hiểu các thành phần tạo nên Team Build.

Tìm hiểu các chức năng của Team Build cung cấp.

Chọn một chiến lược build phù hợp.

Xác định phương pháp mà chiến lược build của bạn có thể cần được thay đổi nếu bạn làm trên một project lớn.

Overview

Chương này giải thích bằng cách nào bạn có thể sử dụng Team Build để tự động hóa quá trình thiết kế(build process). Nó vạch ra một số các sai lầm chung liên quan đến quy trình build (common build-related stumbling blocks) và so sánh các phương pháp tiếp cận khác nhau để builds ranging từ các daily scheduled build đến các continuous integration builds.

Team Build được thiết kế ở đầu của Microsoft Build Engine (MSBuild) và bạn có thể sử dụng nó để lấy các source code cần thiết cho một build, biên dịch các solution và (nếu có yêu cầu) thực thi các kiểm thử đơn vị( unit test) và công cụ phân tích code tĩnh như một phần của quá trình thiết kế(build process). Bạn cũng có thể phát hành các build đầu ra đến một shared location(vị trí chia sẻ) cụ thể.

Team Build labels source code được sử dụng cho một loại build đặc biệt với một số các build để bạn có thể lấy source được sử dụng để khởi tạo một build cụ thể tại một số điểm trong tương lai. Trong trường hợp thất bại, bạn có thể cấu hình Team Build để khởi tạo các work item và để lưu ý cho các người sử dụng về các build failures gặp phải.

How to Use This Chapter

Sử dụng chương này để tìm hiểu về các chức năng mà Team Build cung cấp cho việc tự động hóa và quản lý quá trình build, và để hiểu về các chiến lược khác nhau cho việc lập kế hoạch build. Để đạt được lợi ích cao nhất từ chương này, bạn nên:

§ Đọc "Chapter 8 - Setting up Continuous Integration with Team Build" để tìm hiểu nhiều hơn về việc sử dụng continuous integration với Team Foundation Server (TFS).

§ Đọc "Chapter 9 - Setting up Scheduled Builds with Team Build" để tìm hiểu nhiều hơn về việc sử dụng các scheduled builds.

§ Đọc các đề tài How To kèm theo để giúp thực hiện các nhiệm vụ liên quan đến build:

How To: Tự động Run Code Analysis với Team Build trong Visual Studio Team Foundation Server.

How To: Cài đặt một Continuous Integration Build trong Visual Studio Team Foundation Server.

How To: Cài đặt một Scheduled Build trong Visual Studio Team Foundation Server.

Download tài liệu tại đây: Part III- Chapter 7

Chương 7 - Team Build Explained

Nguyễn Thị Như Quỳnh — Thu, 17 Sep 2009 16:54:50 GMT
Revision 2 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/18/2009 12:54:50 AM

Chương 7 - Team Build Explained

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="ProgId" content="Word.Document" /> <meta name="Generator" content="Microsoft Word 12" /> <meta name="Originator" content="Microsoft Word 12" /> <link rel="File-List" href="file:///C:%5CUsers%5Ckpopyo%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml" /> <link rel="themeData" href="file:///C:%5CUsers%5Ckpopyo%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx" /> <link rel="colorSchemeMapping" href="file:///C:%5CUsers%5Ckpopyo%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml" />  <style></style>  

PART III <o:p></o:p>

Builds <o:p></o:p>

In This Part: <o:p></o:p>

 Team

Team Build Explained



Setting Up Continuous Integration with Team Build

 Setting

Setting Up Scheduled Builds with Team Build

Chương 7 - Team Build Explained

Objectives

Tìm hiểu kiến trúc Microsoft® Visual Studio® Team System Team Build .

Tìm hiểu các thành phần tạo nên Team Build.

Tìm hiểu các chức năng của Team Build cung cấp.

Chọn một chiến lược build phù hợp.

Xác định phương pháp mà chiến lược build của bạn có thể cần được thay đổi nếu bạn làm trên một project lớn.

Overview

Chương này giải thích bằng cách nào bạn có thể sử dụng Team Build để tự động hóa quá trình thiết kế(build process). Nó vạch ra một số các sai lầm chung liên quan đến quy trình build (common build-related stumbling blocks) và so sánh các phương pháp tiếp cận khác nhau để builds ranging từ các daily scheduled build đến các continuous integration builds.

Team Build được thiết kế ở đầu của Microsoft Build Engine (MSBuild) và bạn có thể sử dụng nó để lấy các source code cần thiết cho một build, biên dịch các solution và (nếu có yêu cầu) thực thi các kiểm thử đơn vị( unit test) và công cụ phân tích code tĩnh như một phần của quá trình thiết kế(build process). Bạn cũng có thể phát hành các build đầu ra đến một shared location(vị trí chia sẻ) cụ thể.

Team Build labels source code được sử dụng cho một loại build đặc biệt với một số các build để bạn có thể lấy source được sử dụng để khởi tạo một build cụ thể tại một số điểm trong tương lai. Trong trường hợp thất bại, bạn có thể cấu hình Team Build để khởi tạo các work item và để lưu ý cho các người sử dụng về các build failures gặp phải.

How to Use This Chapter

Sử dụng chương này để tìm hiểu về các chức năng mà Team Build cung cấp cho việc tự động hóa và quản lý quá trình build, và để hiểu về các chiến lược khác nhau cho việc lập kế hoạch build. Để đạt được lợi ích cao nhất từ chương này, bạn nên:

§ Đọc "Chapter 8 - Setting up Continuous Integration with Team Build" để tìm hiểu nhiều hơn về việc sử dụng continuous integration với Team Foundation Server (TFS).

§ Đọc "Chapter 9 - Setting up Scheduled Builds with Team Build" để tìm hiểu nhiều hơn về việc sử dụng các scheduled builds.

§ Đọc các đề tài How To kèm theo để giúp thực hiện các nhiệm vụ liên quan đến build:

How To: Tự động Run Code Analysis với Team Build trong Visual Studio Team Foundation Server.

How To: Cài đặt một Continuous Integration Build trong Visual Studio Team Foundation Server.

How To: Cài đặt một Scheduled Build trong Visual Studio Team Foundation Server.

Tài liệu chương 7 các bạn hãy download tại đây nhé:

PartIII-Chapter7

Chương 7 - Team Build Explained

Nguyễn Thị Như Quỳnh — Thu, 17 Sep 2009 16:50:56 GMT
Revision 1 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/18/2009 12:50:56 AM

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="ProgId" content="Word.Document" /> <meta name="Generator" content="Microsoft Word 12" /> <meta name="Originator" content="Microsoft Word 12" /> <link rel="File-List" href="file:///C:%5CUsers%5Ckpopyo%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_filelist.xml" /> <link rel="themeData" href="file:///C:%5CUsers%5Ckpopyo%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_themedata.thmx" /> <link rel="colorSchemeMapping" href="file:///C:%5CUsers%5Ckpopyo%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C01%5Cclip_colorschememapping.xml" />  <style></style>  

PART III <o:p></o:p>

Builds <o:p></o:p>

In This Part: <o:p></o:p>

 Team Build Explained

Setting Up Continuous Integration with Team Build

 Setting Up Scheduled Builds with Team Build

Objectives

Tìm hiểu kiến trúc Microsoft® Visual Studio® Team System Team Build .

Tìm hiểu các thành phần tạo nên Team Build.

Tìm hiểu các chức năng của Team Build cung cấp.

Chọn một chiến lược build phù hợp.

Xác định phương pháp mà chiến lược build của bạn có thể cần được thay đổi nếu bạn làm trên một project lớn.

Overview

Chương này giải thích bằng cách nào bạn có thể sử dụng Team Build để tự động hóa quá trình thiết kế(build process). Nó vạch ra một số các sai lầm chung liên quan đến quy trình build (common build-related stumbling blocks) và so sánh các phương pháp tiếp cận khác nhau để builds ranging từ các daily scheduled build đến các continuous integration builds.

Team Build được thiết kế ở đầu của Microsoft Build Engine (MSBuild) và bạn có thể sử dụng nó để lấy các source code cần thiết cho một build, biên dịch các solution và (nếu có yêu cầu) thực thi các kiểm thử đơn vị( unit test) và công cụ phân tích code tĩnh như một phần của quá trình thiết kế(build process). Bạn cũng có thể phát hành các build đầu ra đến một shared location(vị trí chia sẻ) cụ thể.

Team Build labels source code được sử dụng cho một loại build đặc biệt với một số các build để bạn có thể lấy source được sử dụng để khởi tạo một build cụ thể tại một số điểm trong tương lai. Trong trường hợp thất bại, bạn có thể cấu hình Team Build để khởi tạo các work item và để lưu ý cho các người sử dụng về các build failures gặp phải.

How to Use This Chapter

Sử dụng chương này để tìm hiểu về các chức năng mà Team Build cung cấp cho việc tự động hóa và quản lý quá trình build, và để hiểu về các chiến lược khác nhau cho việc lập kế hoạch build. Để đạt được lợi ích cao nhất từ chương này, bạn nên:

Đọc "Chapter 8 - Setting up Continuous Integration with Team Build" để tìm hiểu nhiều hơn về việc sử dụng continuous integration với Team Foundation Server (TFS).

Đọc "Chapter 9 - Setting up Scheduled Builds with Team Build" để tìm hiểu nhiều hơn về việc sử dụng các scheduled builds.

Đọc các đề tài How To kèm theo để giúp thực hiện các nhiệm vụ liên quan đến build:

How To: Tự động Run Code Analysis với Team Build trong Visual Studio Team Foundation Server.

How To: Cài đặt một Continuous Integration Build trong Visual Studio Team Foundation Server.

How To: Cài đặt một Scheduled Build trong Visual Studio Team Foundation Server.

Tài liệu chương 7 các bạn hãy download tại đây nhé:

PartIII-Chapter7

Chapter 8 - Setting Up Continuous Integration with Team Build

Nguyễn Thị Như Quỳnh — Thu, 17 Sep 2009 17:04:31 GMT
Current revision posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/18/2009 1:04:31 AM

Chapter 8 - Setting Up Continuous Integration with Team Build

Objectives

Tìm hiểu mục đích của một continuous integration build.

Cài đặt continuous integration bằng cách sử dụng Microsoft® Visual Studio® Team System Team Build.

Tối ưu hóa continuous integration build của bạn để giảm các bottlenecks(sự bế tắc).

Overview

Chương này giải thích cho bạn bằng cách nào bạn có thể cài đặt các continuous integration builds với Team Build và Microsoft Visual Studio Team Foundation Server (TFS). Bạn sử dụng continuous integration builds để nhanh chóng lấy các phản hồi về chất lượng build ngay sau khi một check-in càng tốt. Trong suốt quá trình phát triển nhóm, điều quan trọng nhất là lấy được các phản hồi nhanh chóng về chất lượng của các check-in, đặc biệt là chúng nối với sự thay đổi của các lập trình viên khác và các break the build.

Một continuous integration build cho bạn một cơ hội để sửa mã nhanh chóng unblock( không cấm) các thành viên của các đội khác, qua đó nâng cao tính nhất quán và chất lượng của build của bạn.

Team Foundation Server mặc định không hỗ trợ các continuous integration builds. Có thể là, với sự giúp đỡ của một Microsoft-supplied extension, để mở rộng build engine để hỗ trợ cho continuous integration.

How to Use This Chapter

Sử dụng chương này để học các chiến thuật cho các continuous integration và để tìm hiểu bằng cách nào cài đặt và cấu hình các continuous integration builds với Team Build. Bằng cách đi qua từng bước để giúp bạn thiết lập continuous integration build hãy xem "How To: Set Up a Continuous Integration Build."

Nếu bạn cảm thấy lạ lẫm về TFS và Team Build, hoặc nếu bạn muốn tìm hiểu nhiều hơn về các tùy chọn có sẵn đối với automating và scheduling builds, hãy đọc "Chương 7 - Team Build Explained" trước khi đọc chương này.

Strategies for Continuous Integration Builds

Continuous integration (CI) là quy trình của việc tạo các builds bất cứ khi nào một lập trình viên kiểm tra code trong source control. Sau đây là danh sách về các chiến lược khác nhau sử dụng cho continuous integration builds:

Build on each check-in.

Rolling build after a specific number of check-ins.

Rolling build after a specific time interval.

Rolling build after a specific number of check-ins or time interval.

Build on Each Check-In

Building ngay lập tức sau khi tất cả các check-in là chiến lược continuous integration đơn giản nhất và nói chung cung cấp cho bạn các thông tin feedback nhanh nhất. Tuy nhiên, nếu các check-in diễn ra nhanh chóng đủ để overwhelm các build server, 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 khoảng thời gian nhất định. Để xác định xem nếu bạn cần sử dụng một rolling build, hãy xác định những điều sau:

Length of your team build in minutes( Độ dài của các team build của bạn tính bằng phút).

Average frequency of check-ins in minutes(Tần số trung bình của các check-in bằng phút)

Time window during which frequent check-ins occur:

Nếu độ dài của các build dài hơn tần số trung bình(average frequency) của các check-in, các build của bạn bắt đầu queue up vì lúc đầu các build chưa được hoàn thành trước khi check-in tiếp theo xảy ra bắt đầu cho các build khác. Nếu build queue phát triển đủ dài, điều này có thể tác động đến các thực thi của build server và blocks(khóa lại) các build khác từ lúc bắt đầu(from being started), như là các scheduled build. Xem lại time window trong suốt khi các check-ins xảy ra và xác định nếu queue có thời gian để clear chính nó sau khi iai đoạn check-in busiest đã qua.

Để có thêm thông tin, hãy xem "How To: Set Up a Continuous Integration Build in Visual Studio Team Foundation Server."

Rolling Build After a Specific Number of Check-ins

Nếu build server của bạn đã overload như là một kết quả của việc khởi tạo các build sau mỗi check-in, bạn có thể chọn để chỉ build sau khi một số các check-in cụ thể được hoàn thành. Trong khi là rolling build solution đơn giản nhất, nó có một số các hạn chế đáng kể. Bởi vì các build server cầu thấy được số các check-in cụ thể trước khi một build được khởi động, check-in cuối cùng của ngày hầu như được bảo đảm không lấy một build và do đó mà các build feedback bị trì hoãn.

Rolling Build After a Specific Time Interval

Tạo ra một build chỉ sau một khoảng thời gian nhất định trôi qua sau khi mỗi check-in là một sự cải thiện trong các building sau một số các check-in cụ thể. Phương pháp này được đảm bảo để tạo một build với một timeframe cụ thể xung quanh mỗi check-in được tạo. Hãy nhớ là mỗi build có thể có một số các associated check-ins khác nhau - một số các build có lẽ chỉ có một check-in, trong khi những cái khác có nhiều hơn. Càng nhiều các check-in trong mỗi build, càng nhiều khó khăn để xác định check-in nào tạo ra các breaking change.

Rolling Build After a Specific Number of Check-Ins or Time Interval

Tạo một build sau khi một khoảng thời gian cụ thể hay một số các check-in (không quan tâm cái nào xảy ra trước) results trong sự bền vững nhất trong rolling builds của bạn trong khi giảm các build server load. Sử dụng một rolling build nếu continuous integration build của bạn tạo một build queue rất dài và kết quả trong các build là diễn ra một thời gian đáng kể sau check-in. Sử dụng một check-in interval để xác định số các check-ins giữa mỗi build. Sử dụng giai đoạn time-out period để chắc là một build sẽ diễn ra thậm chí nếu không có thêm các check-in.

Determining Your Rolling Build Interval

Để xác định các ideal rolling build interval, phân chia tần số trung bình của các check-in bằng độ dài của build của bạn. Thí dụ, nếu bạn có một build mất 10 phút và trung bình một check-in 5 phút bạn có thể gán một check-in interval của hai check-in và một giai đoạn time-out của 10 phút. Điều này giúp đảm bảo rằng các build được hoàn thành trước khi build tiếp theo bắt đầu. Nếu bạn lưu ý thấy load quá mức trên build server của bạn, bạn có thể tăng các giá trị này lên.

Continuous Integration Build in Team Foundation Server

Team Foundation Server 2005 không cung cấp một continuous integration solution out of box, nhưng nó đã cung cấp framework cho bạn để thực thi continuous integration build solution của riêng bạn.

Để có thêm thông tin về cài đặt một continuous integration build với TFS, hãy xem "How To: Setup a Continuous Integration Build in Visual Studio Team Foundation Server." How To article này sử dụng solution đã được Visual Studio Team System development team cung cấp. Solution installs một Web service chạy dưới một account có truy cập đến TFS server. Team Foundation Server có thể gửi một e-mail message hay call một Web service khi các event cụ thể xảy ra. Event mechanism này được sử dụng bởi continuous integration solution để đăng kí một Web service với CheckinEvent, để bất cứ khi nào mà một check in xảy ra, Web service khởi động một Team Build.

Summary

Sử dụng continuous integration builds để kick off một build bât cứ khi nào một lập trình viên kiểm tra code trong source control. Mặc dù Team Build không cung cấp một continuous integration solution out of the box, bạn có thể tùy chỉnh các build và thực thi continuous integration build solution của riêng bạn.

Tuỳ thuộc vào yêu cầu của project cụ thể của bạn, bạn có thể set các continuous integration build như sau:

Continuous Integration build trên mỗi check-in.

Rolling build after a specific number of check-ins or specific time interval (whichever occurs earlier) in order to reduce build server load.

Additional Resources

Để có thêm thông tin về việc làm cách nào để sử dụng Visual Studio Team System continuous integration solution, hãy xem "Continuous Integration Using Team Foundation Build" tại đây

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

Để download Visual Studio Team System continuous integration solution MSI, hãy xem 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à continuous integration trong Team Foundation Server, hãy xem "Extend Team Foundation Server To Enable Continuous Integration" tại http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx

Download tài liệu chương 8 tại đậy: Part III-Chapter 8

Chapter 8 - Setting Up Continuous Integration with Team Build

Nguyễn Thị Như Quỳnh — Thu, 17 Sep 2009 17:02:03 GMT
Revision 3 posted to TFS - Team Foundation System by Nguyễn Thị Như Quỳnh on 9/18/2009 1:02:03 AM

Chapter 8 - Setting Up Continuous Integration with Team Build

Objectives

Tìm hiểu mục đích của một continuous integration build.

Cài đặt continuous integration bằng cách sử dụng Microsoft® Visual Studio® Team System Team Build.

Tối ưu hóa continuous integration build của bạn để giảm các bottlenecks(sự bế tắc).

Overview

Chương này giải thích cho bạn bằng cách nào bạn có thể cài đặt các continuous integration builds với Team Build và Microsoft Visual Studio Team Foundation Server (TFS). Bạn sử dụng continuous integration builds để nhanh chóng lấy các phản hồi về chất lượng build ngay sau khi một check-in càng tốt. Trong suốt quá trình phát triển nhóm, điều quan trọng nhất là lấy được các phản hồi nhanh chóng về chất lượng của các check-in, đặc biệt là chúng nối với sự thay đổi của các lập trình viên khác và các break the build.

Một continuous integration build cho bạn một cơ hội để sửa mã nhanh chóng unblock( không cấm) các thành viên của các đội khác, qua đó nâng cao tính nhất quán và chất lượng của build của bạn.

Team Foundation Server mặc định không hỗ trợ các continuous integration builds. Có thể là, với sự giúp đỡ của một Microsoft-supplied extension, để mở rộng build engine để hỗ trợ cho continuous integration.

How to Use This Chapter

Sử dụng chương này để học các chiến thuật cho các continuous integration và để tìm hiểu bằng cách nào cài đặt và cấu hình các continuous integration builds với Team Build. Bằng cách đi qua từng bước để giúp bạn thiết lập continuous integration build hãy xem "How To: Set Up a Continuous Integration Build."

Nếu bạn cảm thấy lạ lẫm về TFS và Team Build, hoặc nếu bạn muốn tìm hiểu nhiều hơn về các tùy chọn có sẵn đối với automating và scheduling builds, hãy đọc "Chương 7 - Team Build Explained" trước khi đọc chương này.

Strategies for Continuous Integration Builds

Continuous integration (CI) là quy trình của việc tạo các builds bất cứ khi nào một lập trình viên kiểm tra code trong source control. Sau đây là danh sách về các chiến lược khác nhau sử dụng cho continuous integration builds:

Build on each check-in.

Rolling build after a specific number of check-ins.

Rolling build after a specific time interval.

Rolling build after a specific number of check-ins or time interval.

Build on Each Check-In

Building ngay lập tức sau khi tất cả các check-in là chiến lược continuous integration đơn giản nhất và nói chung cung cấp cho bạn các thông tin feedback nhanh nhất. Tuy nhiên, nếu các check-in diễn ra nhanh chóng đủ để overwhelm các build server, 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 khoảng thời gian nhất định. Để xác định xem nếu bạn cần sử dụng một rolling build, hãy xác định những điều sau:

Length of your team build in minutes( Độ dài của các team build của bạn tính bằng phút).

Average frequency of check-ins in minutes(Tần số trung bình của các check-in bằng phút)

Time window during which frequent check-ins occur:

Nếu độ dài của các build dài hơn tần số trung bình(average frequency) của các check-in, các build của bạn bắt đầu queue up vì lúc đầu các build chưa được hoàn thành trước khi check-in tiếp theo xảy ra bắt đầu cho các build khác. Nếu build queue phát triển đủ dài, điều này có thể tác động đến các thực thi của build server và blocks(khóa lại) các build khác từ lúc bắt đầu(from being started), như là các scheduled build. Xem lại time window trong suốt khi các check-ins xảy ra và xác định nếu queue có thời gian để clear chính nó sau khi iai đoạn check-in busiest đã qua.

Để có thêm thông tin, hãy xem "How To: Set Up a Continuous Integration Build in Visual Studio Team Foundation Server."

Rolling Build After a Specific Number of Check-ins

Nếu build server của bạn đã overload như là một kết quả của việc khởi tạo các build sau mỗi check-in, bạn có thể chọn để chỉ build sau khi một số các check-in cụ thể được hoàn thành. Trong khi là rolling build solution đơn giản nhất, nó có một số các hạn chế đáng kể. Bởi vì các build server cầu thấy được số các check-in cụ thể trước khi một build được khởi động, check-in cuối cùng của ngày hầu như được bảo đảm không lấy một build và do đó mà các build feedback bị trì hoãn.

Rolling Build After a Specific Time Interval

Tạo ra một build chỉ sau một khoảng thời gian nhất định trôi qua sau khi mỗi check-in là một sự cải thiện trong các building sau một số các check-in cụ thể. Phương pháp này được đảm bảo để tạo một build với một timeframe cụ thể xung quanh mỗi check-in được tạo. Hãy nhớ là mỗi build có thể có một số các associated check-ins khác nhau - một số các build có lẽ chỉ có một check-in, trong khi những cái khác có nhiều hơn. Càng nhiều các check-in trong mỗi build, càng nhiều khó khăn để xác định check-in nào tạo ra các breaking change.

Rolling Build After a Specific Number of Check-Ins or Time Interval

Tạo một build sau khi một khoảng thời gian cụ thể hay một số các check-in (không quan tâm cái nào xảy ra trước) results trong sự bền vững nhất trong rolling builds của bạn trong khi giảm các build server load. Sử dụng một rolling build nếu continuous integration build của bạn tạo một build queue rất dài và kết quả trong các build là diễn ra một thời gian đáng kể sau check-in. Sử dụng một check-in interval để xác định số các check-ins giữa mỗi build. Sử dụng giai đoạn time-out period để chắc là một build sẽ diễn ra thậm chí nếu không có thêm các check-in.

Determining Your Rolling Build Interval

Để xác định các ideal rolling build interval, phân chia tần số trung bình của các check-in bằng độ dài của build của bạn. Thí dụ, nếu bạn có một build mất 10 phút và trung bình một check-in 5 phút bạn có thể gán một check-in interval của hai check-in và một giai đoạn time-out của 10 phút. Điều này giúp đảm bảo rằng các build được hoàn thành trước khi build tiếp theo bắt đầu. Nếu bạn lưu ý thấy load quá mức trên build server của bạn, bạn có thể tăng các giá trị này lên.

Continuous Integration Build in Team Foundation Server

Team Foundation Server 2005 không cung cấp một continuous integration solution out of box, nhưng nó đã cung cấp framework cho bạn để thực thi continuous integration build solution của riêng bạn.

Để có thêm thông tin về cài đặt một continuous integration build với TFS, hãy xem "How To: Setup a Continuous Integration Build in Visual Studio Team Foundation Server." How To article này sử dụng solution đã được Visual Studio Team System development team cung cấp. Solution installs một Web service chạy dưới một account có truy cập đến TFS server. Team Foundation Server có thể gửi một e-mail message hay call một Web service khi các event cụ thể xảy ra. Event mechanism này được sử dụng bởi continuous integration solution để đăng kí một Web service với CheckinEvent, để bất cứ khi nào mà một check in xảy ra, Web service khởi động một Team Build.

Summary

Sử dụng continuous integration builds để kick off một build bât cứ khi nào một lập trình viên kiểm tra code trong source control. Mặc dù Team Build không cung cấp một continuous integration solution out of the box, bạn có thể tùy chỉnh các build và thực thi continuous integration build solution của riêng bạn.

Tuỳ thuộc vào yêu cầu của project cụ thể của bạn, bạn có thể set các continuous integration build như sau:

Continuous Integration build trên mỗi check-in.

Rolling build after a specific number of check-ins or specific time interval (whichever occurs earlier) in order to reduce build server load.

Additional Resources

Để có thêm thông tin về việc làm cách nào để sử dụng Visual Studio Team System continuous integration solution, hãy xem "Continuous Integration Using Team Foundation Build" tại đây

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

Để download Visual Studio Team System continuous integration solution MSI, hãy xem 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à continuous integration trong Team Foundation Server, hãy xem "Extend Team Foundation Server To Enable Continuous Integration" tại http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx

Download tài liệu chương 8 tại đậy: Part III-Chapter 8