công nghệ mã nguồn mở cho các nhà lập trình viên chuyên nghiệp

công nghệ mã nguồn mở cho các nhà lập trình viên chuyên nghiệp

Team Development with Visual

Studio Team Foundation Server

Kevin Jones

Thông tin trong tài liệu này, bao gồm cả URL và những trang Web tham khảo khác trên Internet, thì có thể thay đổi mà không cần thông báo Trừ những thông báo khác, ví dụ như các công ty, các tổ chức, các sản phẩm, tên domain, địa chỉ e-mail, các logo, con người, địa điểm, và thậm chí là những mô tả trong tài liệu này đều là

hư cấu, và không có liên hệ gì đến bất kỳ công ty có thật nào, tổ chức, sản phẩm, tên domain, địa chỉ email, logo, con người, địa điểm, hay thậm chí là những ý định hay những phỏng đoán Tuân thủ tất cả các áp dụng luật bản quyền là trách nhiệm của người sử dụng Không giới hạn các quyền theo bản quyền, không có phần nào trong tài liệu này có thể được sao chép, lưu giữ hoặc được giới thiệu vào một hệ thống, hoặc được truyền tải dưới mọi hình thức hoặc của bất kỳ phương pháp nào (điện tử, cơ khí, photocopy, ghi âm, hoặc khác), hoặc cho bất cứ mục đích nào, mà không có sự đồng ý bằng văn bản cho phép của Tập đoàn Microsoft

Microsoft được cấp bằng sáng chế, các ứng dụng được cấp bằng , nhãn hiệu, bản quyền tác giả, hoặc các quyền sở hữu trí tuệ bao gồm các chủ đề trong tài liệu này Ngoại trừ vì lí do rõ ràng được cung cấp trong bất kỳ thỏa thuận nào bằng văn bản giấy phép từ Microsoft, sự cung cấp tài liệu này không cung cấp cho bạn bất kỳ giấy phép bằng sáng chế nào, nhãn hiệu, bản quyền tác giả, hoặc các sở hữu trí tuệ

© 2007 Microsoft Corporation Giới hạn tất cả các quyền

Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Active Directory, MSDN, Visual Basic, Visual C++, Visual C#, Visual Studio, và cả Win32 đã được đăng kí thương hiệu của Tập đoàn Microsoft tại United States hoặc tại các quốc gia khác

Tên của các công ty thực tế và các sản phẩm được đề cập ở đây có thể là thương hiệu của chủ sở hữu tương ứng

Giới thiệu

Tài liệu này sẽ trình bày cho bạn bằng cách nào nắm bắt được phần tuyệt nhất của

Visual Studio 2005 Team Foundation Server để giúp nâng cao hiệu quả của đội

ngũ phát triển phần mềm cơ bản của bạn

Mặc dù bạn đang sử dụng Team Foundation Server hay đã áp dụng từ đầu, bạn sẽ tìm thấy những hướng dẫn cụ thể và hiểu thấu đáo để điều chỉnh cho phù hợp với tình huống cụ thể của bạn

Những thông tin trong tài liệu hướng dẫn này dựa trên các phản hồi thực tế của khách hàng và hỗ trợ sản phẩm, cũng như là những kinh nghiệm từ các lĩnh vực và trong những chuyên ngành Tài liệu hướng dẫn này trình bày những chức năng cơ bản và gồm có những phần sau

• Phần I, “Cơ bản,” cho bạn một cái nhìn tổng quan một cách nhanh chóng của các đội ngũ phát triển phần mềm với Team Foundation Server Bạn sẽ hình dung

ra một bức tranh lớn trong những điều kiện của môi trường phát triển phần mềm của bạn, bao gồm cả môi trường phát triển và kiểm thử Bạn cũng sẽ tìm hiểu kiến trúc

cơ bản của Team Foundation Server

• Phần II, “Source Control,” trình bày cho bạn bằng cách nào để kết cấu source

code của bạn và quản lý những phần phụ thuộc(là những phần tham khảo từ bên ngoài) Nó cũng trình bày cho bạn bằng cách nào để quyết định một chiến thuật phân nhánh và hợp nhất(branching and merging strategy) nếu bạn cần tách biệt cho các nỗ lực phát triển của bạn

• Phần III, “Builds,” trình bày cho bạn bằng cách nào để thiết lập các team build, làm cách nào để tạo ra các continuous integration build cho đội ngũ phát triển của bạn, và bằng cách nào để chuyển những scheduled builds đến đội ngũ kiểm thử

của bạn Thảo luận về các vấn đề phổ biến và làm sao để giải quyết chúng

• Phần IV, “Xem xét các Dự án lớn,” nêu rõ những lời khuyên bổ sung mà bạn

cần khi làm việc với những dự án lớn

• Phần V, “Quản lý Dự án,” trình bày cho bạn bằng cách nào để sử dụng Team

Foundation Server work items, areas và iterations để đơn giản hóa tiến trình phát triển của bạn bất kể cách tiếp cận quản lý dự án nào bạn đang sử dụng

• Phần VI, “Quy trình mẫu,” trình bày cho bạn làm thế nào để đạt được kết quả tốt

nhất từ những quy trình mẫu và quy trình hướng dẫn được cung cấp kèm với Team Foundation Server Nó còn trình bày cho bạn bằng cách nào bạn có thể tùy chỉnh

những process template, và tạo những điều chỉnh đối với các work items và

workflow để map đến quy trình thiết kế phần mềm mà đội của bạn đang sử dụng

• Phần VII, “Report,” trình bày cho bạn làm thế nào mà tất cả những thành phần

khác của Team Foundation Server hợp nhất dữ liệu của chúng lưu trữ trong một cơ

cấu report chung Bạn sẽ học cách để sử dụng những report mặc định cũng như là cách để xây dựng những report của riêng bạn

• Phần VIII, “Thiết lập và cài đặt Team Environment,” loại bỏ những điều bí ẩn trong sự triển khai Team Foundation Server Bạn sẽ học cách để chọn giữa việc

triển khai một server đơn (single server) và server đa (multiple server) Bạn cũng sẽ học làm sao để hỗ trợ các đội phát triển ở xa và làm thế nào để nâng cao tối đa hiệu

suất của Team Foundation Server

• Phần IX, “Visual Studio 2008 Team Foundation Server”, hiển thị những thay đổi hứa hẹn trong phiên bản kế tiếp của Team Foundation Server Bạn sẽ học

những chức năng mới đã được dự kiến cũng như là những chức năng sẽ được cải thiện đáng kể Một số các thay đổi tác động đến tài liệu hướng dẫn này chúng tôi sẽ trình bày ở một nơi khác trong tài liệu này, vì vậy sử dụng tài liệu này để cải thiện kế

hoạch nâng cấp Team Foundation Server

• Hướng dẫn, cung cấp các lời giới thiệu ngắn gọn cho Team Server Build,

Project Management, Reporting và Source Control Mỗi phần hướng dẫn sẽ cho

bạn biết phải làm gì, tại sao và như thế nào để làm theo phần hướng dẫn đó

• Bài tập, cung cấp một loạt các bài tập hay nhất dựa trên các bài học mà những nhóm phát triển đã nghiên cứu khi sử dụng Team Foundation Server trong các lĩnh vực và với Microsoft Mỗi bài tập tập trung vào việc làm sao để hoàn thành một nhiệm vụ quan trọng có hiệu quả của đội với Team Foundation Server

• Câu hỏi và Trả lời, cung cấp những câu trả lời cho những câu hỏi chung trên Team Foundation Source Control

• Làm thế nào, sẽ cung cấp cho bạn từng bước trong bài hướng dẫn kĩ càng để làm thế nào hoàn thành những nhiệm vụ cụ thể với Team Foundation Server

• Tài nguyên, là một bảng tóm tắt các trang web, nhà cung cấp dịch vụ, các diễn đàn và blog mà bạn có thể sử dụng để học nhiều hơn về Team Foundation Server

và các công cụ được phát triển gần đây nhất

Team Development

Có rất nhiều yếu tố, những quy trình, và những nguyên tắc mà có thể kết nối để cho phép những dự án của đội ngũ phát triển phần mềm thành công Tài liệu hướng dẫn này tập trung vào:

• Quy trình phát triển

• Quy trình xây dựng

• Quy trình quản lý dự án

Sơ đồ sau minh họa mối quan hệ giữa các quy trình phát triển phần mềm điển hình

có liên quan đến đội ngũ phát triển và cách thức mà Team Foundation Server có

thể mang đến sự hỗ trợ cho các nền tảng trong những bước khởi đầu này

Phạm vi

Tài liệu hướng dẫn này tập trung vào việc triển khai Team Foundation Server và

sử dụng nó một cách hiệu quả cho các source control, build automation, quản lý các work item, và quản lý các quy trình

Dưới đây là sơ đồ phác thảo một hệ thống xử lý đơn giản hợp lý của Team

Foundation Server vì nó quan hệ với những quy tắc chung nhất của vòng đời phát

triển và thiết kế phần mềm

Tại sao chúng tôi viết Tài Liệu này?

Từ kinh nghiệm riêng của chúng tôi với Team Foundation Server và thông qua các cuộc hội thảo với khách hàng và các nhân viên Microsoft làm việc trong các lĩnh vực, chúng tôi xác định được nhu cầu về một tài liệu hướng dẫn cách sử dụng Team Foundation trong

thế giới thực Trong khi có thông tin trong tài liệu hướng dẫn sử dụng sản phẩm, các bài

đăng trong các blog và trong các diễn đàn, lại không có một nơi riêng biệt nào để tìm kiếm

các bài tập chứng minh cho hiệu quả của việc sử dụng Team Foundation Server trong bối

cảnh của một dự án phát triển phần mềm trong thế giới thực đầy khó khăn

Ai nên đọc Tài Liệu này

Tài liệu hướng dẫn này là mục tiêu cung cấp cho các cá nhân tham gia vào quy trình phát triển phần mềm với các tài nguyên, những patterns và những bài tập để tạo nên môi trường nhóm phát triển hiệu quả Sau đây là những ví dụ của những vai trò sẽ mang lại lợi ích từ tài liệu hướng dẫn này:

• Một nhóm phát triển muốn áp dụng Team Foundation

• Một quản lý dự án muốn tận dụng tối đa tiềm năng của Team Foundation, với sự quan

tâm đến quản lý các dự án và những nỗ lực phát triển, cung cấp điều kiện cho những bước đầu tiên phát triển phần mềm và cung cấp phản hồi đến các bên kinh doanh liên quan

• Quan tâm đến những đội đang nghiên cứu sử dụng Team Foundation nhưng không biết

nó sẽ đáp ứng tốt đến đâu trong bối cảnh phát triển và những hạn chế về mặt đội nhóm

• Các cá nhân với nhiệm vụ lập kế hoạch triển khai và cài đặt Team Foundation

Sử dụng tài liệu này như thế nào?

Tài liệu hướng dẫn này được chia thành nhiều phần dựa trên thứ tự mà chúng tôi thấy hầu hết các đội nghĩ và ứng dụng Team Foundation Nếu bạn đang trong một quy trình ứng dụng Team Foundation bạn sẽ có lẽ muốn đọc hết tài liệu này từ đầu đến cuối Nếu bạn đang sử dụng một số phần đặc biệt của Team Foundation , như là Source Control hay Team Build, bạn có thể hạn chế chỉ đọc ở những phần đó Sử dụng những chương chính

để tìm hiểu các khái niệm và hướng dẫn các nguyên lý Sử dụng phụ lục của những bài viết

―Hướng dẫn‖, ―Bài tập‖, ―Làm thế nào‖ và ―Cẩu hỏi và Trả lời‖ để nhảy vào việc triển khai thực hiện các chi tiết Sự tách biệt này cho phép bạn hiểu các chủ đề trước và sau đó nhảy vào phần chi tiết mà bạn thấy thích hợp

Cách tổ chức của tài liệu này

Bạn có thể đọc tài liệu này từ đầu đến cuối hoặc là chỉ đọc những chương cần thiết cho công việc của bạn

• Phần VIII, Cài đặt và Duy trì Môi trường Nhóm phát triển

• Phần IX, Visual Studio 2008 Team Foundation Server

Phần I, Cơ Bản

• Chương 01 – Giới thiệu môi trường Team Environment

• Chương 02 – Cấu trúc Team Foundation Server

Phần II, Source Control

• Chương 03 –Cấu trúc các Project và Solutions trong Source Control

• Chương 04 – Cấu trúc các Project và Solutions trong Team Foundation Source Control

• Chương 05 – Xác định chiến lược Branching và Merging của bạn

• Chương 06 – Quản lý các Source Control phụ thuộc trong Visual Studio Team System

Phần III, Builds

• Chương 07 – Giải thích về Team Build

• Chương 08 – Thiết lập các Continuous Integration với Team Build

• Chương 09 – Thiết lập các Scheduled Builds với Team Build

Phần IV, Xem xét các Dự Án lớn

• Chương 10 – Xem xét các Dự Án lớn

Phần V, Quản lý Dự án

• Chương 11 – Giải thích về Quản lý Dự án

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

Phần VI, Các Quy Trình Mẫu

• Chương 13 – Giải thích về Quy Trình Mẫu

• Chương 14 – MSF for Agile Software Development Projects

Phần VII, Report

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

PhầnVIII, Cài đặt và Duy trì Môi trường Nhóm phát triển

• Chương 16 – Triển khai Team Foundation Server

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

Phần IX, Visual Studio 2008 Team Foundation Server

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

Hướng dẫn

• Hướng dẫn: Team Build

• Hướng dẫn: Source Control

• Hướng dẫn: Report

• Hướng dẫn: Quản lý dự án

Bài tập

• Bài tập tại một Glance: Team Build

• Bài tập tại một Glance: Source Control

• Bài tập tại một Glance: Reporting

• Bài tập tại một Glance: Project Management

Câu hỏi và Trả lời

• Câu hỏi và Trả lời: Team Foundation Server Source Control và Versioning ―Làm thế nào‖

• Làm thế nào: Thêm một nhà lập trình vào dự án của bạn trong Visual Studio Team

Foundation

Server

• Làm thế nào: Chạy tự động Code Analysis với Team Build trong Visual Studio Team

Foundation Server

• Làm thế nào: Tạo một Report theo ý bạn với Visual Studio Team Foundation Server

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

• Làm thế nào: Tạo một Check-in Policy theo ý bạn trong Visual Studio Team Foundation Server

• Làm thế nào: Tạo Source Tree của bạn trong Visual Studio Team Foundation Server

• Làm thế nào: Tùy chỉnh một Process Template trong Visual Studio Team Foundation Server

• Làm thế nào: Tùy chỉnh một Report trong Visual Studio Team Foundation Server

• Làm thế nào: Quản lý các dự án trong Visual Studio Team Foundation Server

• Làm thế nào: Di chuyển Source code đến Team Foundation Server từ Visual Source Safe

• Làm thế nào: Thực hiện một Baseless Merge trong Visual Studio Team Foundation Server

• Làm thế nào: Cài đặt một Continuous Integration Build trong Visual Studio Team

Foundation

Server

• Làm thế nào: Cài đặt một Scheduled Build trong Visual Studio Team Foundation Server

• Làm thế nào: Cấu trúc ASP.NET Application của bạn trong Visual Studio Team

Foundation Server

• Làm thế nào: Cấu trúc Windows Applications trong Visual Studio Team Foundation Server

• Làm thế nào: Cấu trúc các thư mục Source Control trong Visual Studio Team Foundation Server

Tài nguyên

• Tài nguyên về Team Foundation Server

Phản hồi và Hỗ trợ

Chúng tôi đã thực hiện mọi nỗ lực để đảm bảo tính chính xác của tài liệu hướng dẫn này và

đi theo nội dung của nó

Phản hồi về Tài liệu này

Nếu bạn muốn bình luận về tài liệu này, hãy gửi e-mail đến địa chỉ

Team Foundation

Server - Setup

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

Server - Process

Templates

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=482

&SiteID=1

• Microsoft Đóng góp/ Xem lại Aaron Hallberg; Ahmed Salijee; Ajay Sudan; Ajoy Krishnamoorthy; Alan Ridlehoover; Alik Levin; Ameya Bhatawdekar; Bijan Javidi; Bill Essary; Brett Keown; Brian Harry; Brian Moor; Brian Keller; Buck Hodges; Burt Harris; Conor Morrison; David Caufield; David Lemphers; Doug Neumann; Edward Jezierski; Eric Blanchet; Eric Charran; Graham Barry; Gregg Boer; Janet Williams Hepler; Jeff Beehler; Jose Parra; Julie MacAller; Ken Perilman; Lenny Fenster; Marc Kuperstein; Mario Rodriguez; Matthew Mitrik; Michael Puleio; Nobuyuki Akama; Paul Goring; Pete Coupland; Peter Provost; Granville (Randy) Miller; Rob Caron; Robert Horvick; Rohit Sharma; Ryley Taketa; Sajee Mathew; Siddharth Bhatia; Tom

Hollander; Tom Marsh; Venky Veeraraghavan

Hãy nói cho chúng tôi biết về thành công của bạn:

Nếu tài liệu này có thể giúp bạn, chúng tôi thật sự muốn biết Hãy cho chúng tôi biết bằng cách viết một tổng kết ngắn ngọn của những vấn đề mà bạn gặp phải và tài liệu này đã giúp bạn như thế nào để vượt qua vấn đề đó Hãy gửi bản tổng kết của bạn đến:

MyStory@Microsoft.com

Phần I

Cơ Bản

Trong phần này:

 Giới thiệu về môi trường Team Environment

 Kiến trúc Team Foundation Server

Chương 1 – Giới thiệu về Team Environment

Chủ đề

• Mô tả Microsoft® Visual Studio® Team Foundation Server hỗ trợ vòng đời phát

triển phần mềm như thế nào

• Mô tả một nhóm phát triển phần mềm điển hình sử dụng Team Foundation Server như thế nào

• Mô tả một nhóm kiểm thử điển hình sử dụng Team Foundation Server như thế nào

• Mô tả môi trường vật lý của nhóm phát triển và nhóm kiểm thử

Xem trước

Chương này mô tả Team Foundation Server (TFS) và Microsoft Visual Studio Team System (VSTS) được sử dụng như thế nào trong một môi trường của những đội ngũ phát triển phần mềm cơ bản Giới thiệu những chức năng cốt lõi của TFS và VSTS

và mô tả sự tương tác qua lại trong tiến trình công việc giữa nhóm phát triển và nhóm kiểm thử trong suốt một dự án phát triển phần mềm Bởi vì TFS tích hợp cả source control, work tracking, báo cáo, quản lý dự án và một quy trình xử lý tự động,

nó có thể làm cho một đội phát triển làm việc với nhau một cách hiệu quả

Một dự án phát triển phần mềm của một nhóm phát triển thành công cần rất nhiều quy trình mà tất cả phải làm việc với nhau một cách suông sẻ để chắc chắn cho một môi trường làm việc năng suất và hiệu quả Những quy trình cốt lõi bao gồm:

• Development : Phát triển/ Lập trình

• Test : Kiểm thử

• Build : Thực thi

• Deployment : Triển khai

• Release: Phát hành

Chương này giới thiệu cho bạn những chức năng đặc trưng mà nhóm phát triển và nhóm kiểm thử có thể thi hành với TFS và mô tả bằng cách nào bạn có thể sử dụng TFS để quản lý tiến trình công việc(workflow) để hỗ trợ một cách hiệu quả sự hợp tác của các đội ngũ phát triển

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

Chương này được sử dụng để nghiên cứu TFS đã được thiết kế để hỗ trợ vòng đời phát triển phần mềm như thế nào Bằng cách đọc chương này, bạn cũng sẽ học về các tiến trình của TFS và bằng cách nào mà TFS có thể giúp bạn nâng cao sự cộng tác của nhóm

Để có thông tin chi tiết về kiến trúc TFS và các thành phần cốt lõi của TFS hãy xem

―Chương 2 – Kiến trúc của Team Foundation Server‖

Tiến trình Logic của Team Foundation Server

TFS cho phép đội phát triển lưu trữ code trong một kho trung tâm quản lý source

code Bạn có thể tạo các build từ kho source code này bằng cách sử dụng build server và sau đó có thể phân phối những build này đến đội ngũ kiểm thử của bạn

Hình 1.1 hiển thị tiến trình logic của TFS và những môi trường phát triển và kiểm thử được kết nối với nhau như thế nào

Hình 1.1 Tiến trình logic của Team Foundation Server

Nhóm kiểm thử chọn những build từ một drop location và chạy chúng thông qua

môi trường kiểm thử bằng việc hiển thị một sự kết hợp giữa kiểm thử bằng tay và tự động Kết quả kiểm thử được lưu trữ bởi TFS và được sử dụng để cung cấp các

thông tin phản hồi về chất lượng build Nhóm kiểm thử còn có thể tạo các work

items và các lỗi(một loại cụ thể của work item) mà trên đó các nhóm phát triển cần hành động.Những work item này cho phép nhóm kiểm thử theo dõi công việc của

nhóm phát triển

Tiến trình logic của Các môi trường Phát triển, Kiểm thử và Sản

phẩm

Trong những tổ chức lớn với nhiều nhóm phát triển , mỗi đội phát triển duy trì một

TFS riêng bao gồm có những kho source code và những server team build riêng Hình 1.2 hiển thị một ví dụ của tiến trình logic mà những kết quả từ hai nhóm phát triển cung cấp những ứng dụng được xây dựng đến một nhóm kiểm thử tích hợp

Hình 1.2 Tiến trình logic hiển thị hai nhóm phát triển phần mềm và một nhóm kiểm thử tích hợp

Mỗi nhóm phát triển cung cấp những scheduled builds đến một drop point ví dụ như là một mạng chia sẻ Những build này được mang đến cho nhóm kiểm thử và được thử nghiệm để đo chất lượng của build Khi đã qua được cánh cửa kiểm thử

chất lượng, ứng dụng được triển khai đến một server được tổ chức cho những kiểm

tra cuối cùng và cho sự chấp nhận của người sử dụng trước khi vào giai đoạn cuối

là triển khai trên một production server

Những quy trình phát triển

Nhà lập trình thực hiện một số lượng các tương tác chính với TFS xuyên suốt

khoảng thời gian của một dự án phát triển phần mềm Thí dụ , nếu là một lập trình viên, bạn tương tác với TFS trong những cách thức sau:

• Bạn truy cập lỗi và các task work items từ TFS để xác định xem những việc gì bạn cần phải làm Thí dụ, những work items phải được phân công từ người quản lý

dự án của bạn, từ những nhà lập trìnhkhác hay là từ nhóm kiểm thử

• Bạn sử dụng VSTS Source Control Explorer để truy cập đến kho TFS source control và source code hoàn chỉnh đầy đủ sau cùng trong một workspace cục bộ

hay máy tính phát triển của bạn

• Sau khi thực hiện các công việc được xác định bởi các work items thì bạn kiểm

tra lại code bằng cách vào cơ sở dữ liệu source control

• Check-in event có thể kích hoạt một continuous integration build sử dụng Team

• Bạn nhận sản phẩm của một scheduled build từ một drop location cụ thể

• Bạn thực hiện kiểm thử bằng tay hay tự động bao gồm có kiểm thử về độ an toàn bảo mật, kiểm thử hiệu suất hoạt động, và kiểm thử Web bằng cách sử dụng những công cụ VSTS khác nhau

• Bạn upload các kết quả từ các kiểm thử đến kho dữ liệu kiểm thử TFS Test

Result database để tham khảo trong tương lai

• Bạn ghi lại các lỗi xác định bằng kiểm thử của bạn vào TFS như là những work item mới

• Bạn giải quyết những lỗi tồn tại, nếu lần build sau cùng đã sửa những lỗi được ghi nhận trước đó

Môi trường vật lý của phát triển và kiểm thử

Quy mô và số lượng máy tính liên kết với những môi trường phát triển và kiểm thử

khác nhau tùy vào quy mô của những dự án và các nhóm của bạn Hình 1.3 hiển

thị một môi trường vật lý của phát triển và kiểm thử điển hình

Hình 1.3 Môi trường vật lý của phát triển phần mềm và kiểm thử

Môi trường phát triển

Môi trường phát triển hỗ trợ những quy trình phát triển và build của bạn Môi trường phát triển chứa những máy tính sau:

 ƒ Một Team Foundation Server

 ƒ Một build server

 ƒ Một server để lưu trữ những drop từ build server

 ƒ Developer workstation

Nếu nhóm phát triển của bạn truy cập TFS từ xa, hay bạn có một nhóm lớn riêng

biệt mà gây ra những vấn đề về hiệu suất trên trung tâm TFS server, bạn cũng có thể thiết kế một TFS proxy để giúp bạn cải thiện hiệu suất

Môi trường kiểm thử

Môi trường kiểm thử bao gồm một hoặc nhiều workstations với Visual Studio

Team Edition for Software Testers được cài đặt Những phần này được sử dụng

để quản lý chu kì kiểm thử và để thực hiện kiểm thử chức năng(functional

testing),kiểm thử hệ thống(system testing), kiểm tra mức độ bảo mật(security

testing), kiểm thử hiệu suất(performance testing), và kiểm thử Web(Web

testing) Những thành viên của nhóm sử dụng TFS để quản lý các work items,các lỗi (bugs), và kết quả kiểm thử

Môi trường kiểm thử còn bao gồm cả Visual Studio Team Test Load dành cho

kiểm tra hiệu suất

Tổng kết

VSTS và TFS được thiết kế để hỗ trợ chu kỳ phát triển phần mềm bằng cách tích

hợp những khía cạnh khác nhau của phát triển phần mềm như là source control, work tracking, report, quản lý dự án, và quy trình build tự động

TFS đóng một vai trò quan trọng trong sự hợp tác giữa nhóm phát triển và nhóm kiểm thử Một nhóm phát triển tương tác với TFS xuyên suốt chu kì phát triển, truy cập các lỗi và các work item để xác định những công việc nào cần được thực hiện

và truy cập vào source control để cho phép thực hiện các phát triển Một nhóm kiểm thử tương tác với TFS để chạy thử nghiệm, tải lên các kết quả kiểm thử, và ghi nhận các lỗi

Các tài nguyên bổ sung

• Để biết thêm thông tin TFS cơ bản, hãy xem ―Team Foundation Server

Fundamentals: A Look at the Capabilities and Architecture‖ tại

http://msdn2.microsoft.com/en-us/library/ms364062(vs.80).aspx

• Để có một cái nhìn khái quát về Team Foundation, hãy xem tài liệu hướng dẫn sản phẩm Team Foundation trên trang web Microsoft MSDN® Web site tại

http://msdn2.microsoft.com/en-us/library/ms181232(vs.80).aspx

Chapter 2 – Kiến trúc Team Foundation Server

Bạn có thể chọn để cài đặt tầng application và tầng data trên cùng một physical server hay trên những server riêng biệt Sự chọn lựa của bạn phần lớn phụ thuộc vào kích cỡ nhóm của bạn Một single-server được triển khai làm việc tốt nhất với những nhóm có số thành viên ít hơn 50 người, nhưng với một máy chủ đủ mạnh mẽ

có thể hỗ trợ tối đa 400 người dùng Một dual-server triển khai quy mô có thể lên đến khoảng 2000 người sử dụng

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

Chương này dùng để nghiên cứu về những thành phần cốt lõi của TFS và chúng tương tác với cái khác như thế nào Đọc chương này, bạn cũng sẽ học về mục đích của mỗi thành phần và cách mà chúng được triển khai một cách thông thường nhất Nếu bạn chưa biết gì về TFS, bạn nên đọc trước ―Chương 1 – Giới thiệu về Team Environment‖, để biết được bằng cách nào mà những nhóm phát triển và kiểm thử tương tác với TFS và sử dụng nó để nâng cao sự hợp tác và cải thiện tổng năng suất của những nỗ lực phát triển phần mềm của họ

Kiến trúc của TFS

TFS một kiến trúc 3 tầng một cách logic, bao gồm tầng client, application, và tầng data TFS clients tương tác với tầng application thông qua những Web services khác nhau; nói cách khác, tầng application được hỗ trợ bởi những database khác nhau trong tầng data

Hình 2.1 hiển thị những thành phần của mỗi tầng của TFS cũng như là sự tương

tác giữa chúng

Hình 2.1 Thành phần và các tầng của TFS

Tầng Client

Tầng client chứa những thành phần quan trọng sau :

• Team Foundation Server object model Đây là public API được sử dụng để

tương tác với TFS Bạn có thể sử dụng object model( mô hình đối tượng) để tạo

những ứng dụng client-side cho riêng bạn mà tương tác với TFS

• Những thành phần Visual Studio Industry Partners (VSIP) Đây là những công

cụ của bên thứ ba(third-party tools), add-ins và những ngôn ngữ được sử dụng

trong Visual Studio

• Microsoft Office tích hợp Phần này bao gồm một bộ các add-ins dành cho

Microsoft Office Excel® và Microsoft Office Project cho phép bạn truy vấn và cập

nhập các work item trong cơ sở dữ liệu TFS Work Item Tracking Điều này đặc biệt hữu ích cho các nhà quản lý dự án đã sử dụng rộng rãi các công cụ này

• Command-line tools Đây là những công cụ cho phép bạn tương tác với TFS từ

những dòng lệnh (command line) Phần lớn các công cụ này cung cấp các chức

năng kiểm soát mã nguồn và chúng hữu ích trong việc tự động hóa các tác vụ lặp và các tác vụ cố định

• Check-in policy framework Thành phần này hỗ trợ check-in policy feature, là

một cơ chế mở rộng cho phép bạn xác nhận tính hợp lệ của code trong suốt

check-in process

Tầng Application

Tầng application trình bày những Web services ASP.NET sau đây được truy cập bởi tầng client Những Web services này không có mục đích để chống lại bên thứ ba(third-party), nhưng được mô tả ở đây cho hoàn chỉnh Những Web services được nhóm vào các tập sau:

 ƒ Team Foundation Data Services

 ƒ Team Foundation Integration Services

Team Foundation Data Services

Tập các Web services này chủ yếu liên quan đến các thao tác dữ liệu trong tầng data Những service này gồm có:

• Version Control Web service Tầng client sử dụng Web service này để thực thi

các chức năng source control TFS khác nhau và để tương tác với source control database

• Work Item Tracking Web service Tầng client sử dụng Web service này để tạo,

cập nhật và truy vấn các work item trong Work Item Tracking database

• Team Foundation Build Web service Tầng client và MSBuild framework sử

dụng Web service này để thực thi các quy trình thiết kế

Team Foundation Integration Services

Tập các Web services này cung cấp các chức năng tự động và thống nhất Những service này không tương tác với tầng data Những dịch vụ Team Foundation

Integration service gồm có:

• Registration Web service Service này được sử dụng để đăng kí các dịch vụ

TFS khác Nó gìn giữ thông tin trong một cơ sở dữ liệu đăng kí Những service sử dụng những thông tin này để khám phá và xác định xem bằng cách nào để tương tác với cái khác

• Security Web service Service này bao gồm Group Security Service và

Authorization Service Group Security Service được dùng để quản lý tất cả các

user và group của TFS Authorization Service cung cấp một hệ thống kiểm soát truy cập cho TFS

• Linking Web service Service này cho phép các công cụ thiết lập một mối quan

hệ được liên kết lỏng lẻo (hay "links") giữa các phần tử dữ liệu mà chúng đang

chứa Thí dụ, mối quan hệ giữa một work item sai sót và source code được thay đổi

để sữa chữa sự sai sót được tổ chức bởi TFS sử dụng một liên kết

• Eventing Web service Service này cho phép một công cụ hay một dịch vụ đăng

ký các loại sự kiện Người sử dụng có thể đồng ý để những sự kiện này và nhận được thông báo qua e-mail hay bởi sự dẫn ra của một Web service Thí dụ, bạn có

thể sử dụng một check-in event để kích hoạt một continuous integration build

• Classification Web service Service này làm việc với Linking Web service để

kích hoạt những thành phần liên quan đến TFS để phân loại tùy theo những

nguyên tắc phân loại đã được định nghĩa trước Dịch vụ này giúp hỗ trợ cross-tool reporting ngay cả đối với những thành phần mà không chia sẻ một nguyên tắc phân loại thông thường nào để tổ chức dữ liệu của chúng Thí dụ, nếu các work item được tổ chức bình thường bởi nhóm của bạn, trong khi test được tổ chức bởi các thành phần, bạn cũng có thể tổ chức test bởi nhóm của bạn để các test đó có thể được báo cáo cùng với các work item

Tầng Data

TFS không hỗ trợ truy cập trực tiếp đến dữ liệu được lưu trữ trên tầng data từ

những ứng dụng client Thay vào đó, tất cả các yêu cầu về dữ liệu phải được thực hiện thông qua các Web services trên tầng application Tầng data của TFS bao gồm các dữ liệu sau được lưu trữ tương ứng với các data services trên tầng application

• Work item tracking Phần này lưu trữ tất cả các dữ liệu có liên quan đến work

items

• Version control Phần này lưu trữ tất cả các dữ liệu có liên quan đến source

control

• Team Foundation Build Phần này lưu trữ tất cả các thông tin liên quan đến các

chức năng của TFS Team Build

• Reporting warehouse Phần này lưu trữ tất cả các thông tin liên quan đến tất cả

các công cụ và chức năng của TFS Reporting warehouse giúp việc tạo ra các báo cáo đơn giản hơn bằng cách kết hợp dữ liệu từ nhiều công cụ khác nhau

Triển khai Topology

Bạn có thể triển khai TFS bằng cách sử dụng một sự khác nhau của vùng topology khác nhau từ việc cài đặt single-server đến topology phức tạp hơn là multiple-

server Bất kể bao nhiêu topology (cấu trúc liên kết) bạn sử dụng , bạn cần phải nhận biết được một số yêu cầu chính

Những yêu cầu chính

Bất kể là bạn chọn triển khai topology nào thì :

• Bạn phải cài đặt tầng application và tầng data trong cùng một domain, mặc dù chúng có thể được đặt trên cùng node server hay là trên một node server riêng lẻ

• Bạn phải cài đặt những máy tính có TFS với Microsoft Windows Server™ 2003 phiên bản Service Pack 1 (SP1) hoặc mới hơn

• Bạn phải cài đặt tất cả các tầng ứng dụng của TFS Web services trên cùng một server

• Bạn phải cài đặt những thể hiện TFS đơn trên một máy tính đơn

• Bạn không thể cài đặt nhiều hơn một thể hiện của TFS trên một server

• Bạn không thể phân tán những database của TFS qua nhiều server dữ liệu Tất

cả các dự án phải tập trung vào một nhóm Team Foundation server, và không thể triển khai trên nhiều nhóm server

• Bạn không thể sử dụng một Microsoft SharePoint® Portal Server infrastructure đã tồn tại để lưu trữ cho cổng dự án của nhóm bạn Hãy cân nhắc việc sử dụng một server dành riêng cho các cổng TFS SharePoint

• Bạn không nên cài đặt TFS trên một server được cấu hình như một domain

controller bởi vì điều này không được hỗ trợ

• Đối với việc triển khai dual-server , bạn cần phải chuẩn bị một vài account domain

để sử dụng khi chạy TFS services Thí dụ, bạn cần tạo các account như là

DOMAIN\TFSSERVICE và DOMAIN\TFSREPORTS

Triển khai Single-Server

Một sự triển khai single-server là một cấu trúc liên kết (topology) đơn giản nhất và dành cho một đội phát triển hay những dự án thí điểm xấp xỉ tối đa 400 user Với phương pháp tiếp cận này, bạn cài đặt tất cả các thành phần của tầng application và tầng data trên một single server và truy cập chúng trên cùng một domain

Nếu bạn cần cài đặt những thành phần trang bị cho việc kiểm thử, bạn có thể cài đặt chúng trên một node server hay là trên một hay nhiều client

Hình 2.2 hiển thị cấu trúc liên kết single-server

Hình 2.2 Cấu trúc liên kết Single Server

Triển khai Dual-Server

Triển khai cấu trúc liên kết dual-server rất có lợi cho các nhóm phát triển lớn cỡ

khoảng 2000 user Trong việc triển khai cấu trúc này, bạn cài đặt tầng application

trên một server node riêng biệt từ tầng data Bạn có thể cài đặt Team Foundation

Build Services trên tầng application, nhưng bạn được khuyến khích để thiết lập một hay nhiều build server dành riêng cho các nhóm lớn Nếu dự án của bạn cần thực hiện kiểm thử, bạn có thể triển khai các thiết bị kiểm thử(controller và agent) đến các sever node bổ sung Hình 2.3 hiển thị cấu trúc liên kết dual-server

Hình 2.3 Dual Server Topology: Cấu trúc liên kết Dual Server

Kết luận

Kiến trúc của Team Foundation Server bao gồm có 3 tầng : một tầng client, một tầng application và một tầng data

• Tầng client chứa các thành phần client như là Team Explorer trong Visual Studio

2005, Microsoft Office integration, và những công cụ dòng lệnh

• Tầng application chứa các thành phần như là Team Foundation version control services, work item tracking services, và build services

• Tầng data chứa các database để lưu trữ data cần thiết cho work item tracking, version control, team build, và reporting warehouse

TFS có hỗ trợ triển khai cấu trúc liên kết single-server và dual-server Trong triển khai một single-server thì tầng application và tầng data được cài đặt trên cùng một máy Sự triển khai single-server thích hợp với những nhóm nhỏ hoặc khi chỉ đạo những dự án thí điểm Trong triển khai dual-server , tầng application và tầng data phải được cài đặt trên những server riêng biệt Triển khai dual-server thích hợp với những nhóm phát triển lớn với số lượng user lớn

Tài nguyên bổ sung:

• Để biết thêm thông tin chi tiết về Team Foundation fundamentals, hãy xem ―Team Foundation Server Fundamentals: A Look at the Capabilities and Architecture‖ tại http://msdn2.microsoft.com/en-us/library/ms364062(vs.80).aspx

• Để có cài nhìn tổng quát về Team Foundation, xem tài liệu hướng dẫn sản phẩm Team Foundation trên trang Microsoft MSDN® Web tại

http://msdn2.microsoft.com/en-us/library/ms181232(vs.80).aspx

• Để biết thêm thông tin về những giới hạn Team Foundation Server scalability, hãy xem ―Team Foundation Server Capacity Planning‖ tại đây:

http://blogs.msdn.com/bharry/archive/2006/01/04/509314.aspx

Phần II

Source Control

Trong phần này:

 Cấu trúc Project và Solution trong Source Control

 Cấu trúc Project và Solution trong Team Foundation Source Control

 Xác định chiến lược Branching và Merging của bạn

 Quản lý Source Control phụ thuộc trong Visual Studio Team System

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

cơ chế mà bạn sử dụng để tham chiếu đến các tập tin phụ thuộc và cũng như là các quy trình

Nếu bạn đang làm việc trên một dự án nhỏ bạn có thể sử dụng một single solution

để chứa tất cả các tập tin dự án của bạn Nếu bạn đang làm việc trên một dự án phát triển phần mềm với một số lượng lớn các tập tin dự án, bạn nên sử dụng

những tập tin multiple solution để nhóm các dự án có liên quan mà tương ứng với nhóm các chức năng của bạn trong tổng thể dự án nhóm Tùy thuộc vào kịch bản cụ thể bạn có thể cũng cần một tập tin single solution để nhóm tất cả các tập tin dự án lại với nhau

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

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

• Sử dụng danh sách các chiến lược Sử dụng danh sách các chiến lược khởi

đầu như: single solution, partitioned solution, và multiple solutions để nhanh chóng đánh giá phương pháp tiếp cận tốt nhất cho kịch bản của bạn

• Đọc những phần kịch bản mà có liên quan nhiều nhất đến nhu cầu của bạn

Đọc phần mô tả làm thế nào để triển khai các tùy chọn mà chọn đã chọn

• Đọc chương 4, “Cấu trúc Projects và Solutions trng Team Foundation Server Source Control” kế tiếp Chương 4 giới thiệu cho bạn những xem xét quan trọng

nên nhớ khi lưu trữ code trong Team Foundation Server (TFS) source control

• Đọc chương 6, “Quản lý Source Control Dependencies trong Visual Studio Team System” Kết cấu project tác động đến các chiến lược có sẵn cho bạn khi

quản lý những thành phần phụ thuộc qua các project và solution Để biết thêm thông tin về bằng cách nào để quản lý các phụ thuộc, hãy đọc chương 6

• Đọc các chủ đề Làm thế nào kèm theo Đọc các chủ đề Làm như thế nào và đi

theo từng bước các thao tác khác nhau được thảo luận trong chương này:

 Làm thế nào: Kết cấu ASP.NET Applications trong Visual Studio Team

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

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

• Single solution Nếu bạn làm việc trên một hệ thống nhỏ, hãy tạo một single

solution và đặt tất cả các file dự án của bạn trên đó

• Partitioned solution Nếu bạn làm việc trên một hệ thống lớn, sử dụng những

multiple solution để nhóm các project liên quan lại với nhau Tạo các solution để nhóm một cách hợp lý các nhóm nhỏ project mà một nhà lập trình hầu như muốn chỉnh sửa như là một tập hợp, và sau đó tạo một master Solution để chứa tất cả các

dự án của bạn Phương pháp tiếp cận này làm giảm bớt số lượng dữ liệu cần được lấy từ source control khi bạn chỉ cần làm việc trên những dự án cụ thể

• Multiple solutions Nếu bạn đang làm việc trên một hệ thống rất lớn mà yêu cầu

hàng chục dự án hay nhiều hơn, hãy sử dụng multiple solution để làm việc trên các

hệ thống con, nhưng đối với dependency mapping và các lý do hiệu suất thì không tạo một master solution để chứa tất cả các project

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

• Sử dụng chiến lược một single solution nếu kết quả solution không quá lớn để load vào Visual Studio

• Sử dụng multiple solutions để tạo những cái nhìn cụ thể trên các hệ thống con của ứng dụng của bạn

• Sử dụng multiple solutions để giảm thời gian load một solution và giảm thời gian build cho các nhà lập trình

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

• Mỗi project đều tạo ra một assembly tại thời gian build Bắt đầu bởi việc xác định assembly nào bạn muốn tạo và sau đó sử dụng nó để quyết định những dự án nào bạn cần Sử dụng nó để quyết định phần code cơ bản nào của bạn được xem như

là nhân tố trong các dự án

• Bắt đầu với cấu trúc single solution đơn giản nhất Chỉ thêm các phần phức tạp vào kết cấu của bạn khi nó thật sự cần thiết

• Khi thiết kế một kết cấu multi-solution:

 Xem xét tính độc lập của dự án Hãy thử nhóm các dự án có phụ thuộc vào nhau như là những phần của cùng một solution Điều này cho phép bạn sử dụng các tham chiếu project trong phạm vi solution của bạn Bằng cách sử dụng các project references thay vì file references, cho phép Visual Studio

để xây dựng cấu hình (debug/release) được đồng bộ hoá , và để theo dõi các version để xác định xem khi nào thì các project cần được built lại Cố gắng giảm thiểu số lượng các tham chiếu qua các solution và project

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

source trong cùng một solution

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

• Giữ một dãy kết cấu project để dễ dàng nhóm các project vào trong các solution

mà không cần phải thay đổi cấu trúc file hệ thống hay thư mục source control

Single Solution

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

Hình 3.1 Single Solution Approach

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

• Bạn có thể giữ các build script đơn giản

• Bạn có thể map dễ dàng các project có tính phụ thuộc ngang nhau trong solution Bạn nên sử dụng cấu trúc này nếu tất cả các nhà lập trình sử dụng cùng một

solution và có cùng một tập các project Điều này có thể là một vấn đề cho các hệ

thống lớn, nơi mà bạn muốn tổ chức các project bằng các hệ thống con hay các

chức năng

Partitioned Solution

Nếu bạn làm việc với một hệ thống lớn, xem xét việc sử dụng các multiple solution, mỗi cái đại diện một hệ thống con trong ứng dụng của bạn Những solution này có thể được các nhà lập trìnhsử dụng để làm việc trên những phần nhỏ hơn của hệ

thống mà không có việc load tất cả các code trên tất cả các project Thiết kế cấu

trúc solution của bạn với bất kì project nào mà có phụ thuộc giữa các nhóm với

nhau Điều này cho phép bạn sử dụng các project reference hơn là các file

reference Hãy xem xét luôn việc tạo một tập tin master solution để chứa tất cả các project Bạn có thể sử dụng điều này để build toàn bộ ứng dụng của bạn

Lưu ý: Không như phiên bản trước của Visual Studio, Visual Studio 2005 dựa theo

MSBuild Hiện thời nó cho phép tạo những cấu trúc solution mà không bao gồm tất

cả các project reference và vẫn còn build không có các error Miễn là master solution được build trước, tạo ra các binary output từ các project, MSBuild có thể theo sau các project references bên ngoài những sự ràng buộc của solution và build thành

công của bạn Nó chỉ làm việc nếu bạn sử dụng project references, không phải là file references Bạn có thể build thành công các solution được tạo bằng phương pháp

này từ Visual Studio build theo các dòng lệnh và từ IDE, nhưng mặc định là không được với Team Build Để build thành công với Team Build hãy sử dụng master

solution bao gồm tất cả các project và các phụ thuộc

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

Hình 3.2 Partitioned Solution Approach

Khi làm việc với các multiple solution, sử dụng một dãy cấu trúc các file cho tất cả các project của bạn Một thí dụ điển hình là một ứng dụng có một Microsoft

Windows® Forms project, một ASP.NET project, một Windows service, và một tập các class library project được chia sẻ bởi một hay tất cả các project này

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

Giữ dãy các cấu trúc này cung cấp nhiều sự linh hoạt và khả năng để sử dụng các solution cho các cách trình bày khác nhau trên những project Cấu trúc thư mục vật

lý xung quanh các file solution này thay đổi rất khó, đặc biệt nếu bạn nhận ra là bạn cần tái sử dụng lại một class library từ một solution khác

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

• Hiệu suất được cải thiện khi tải và xây dựng các ứng dụng solution con

• Các solution con có thể được sử dụng để tạo các ý định trên các tập project dựa trên các đội phát triển con hay các ranh giới của việc chia sẻ code

• Bạn có thể sử dụng master solution để build toàn bộ ứng dụng

• Bạn có thể dễ dàng map các phần dependency trên các project trong mỗi solution con

• Nó giảm sự phức tạp nếu các solution chia nhỏ một cách logic Thí dụ chia nhỏ các solution cùng với các tuyến kĩ thuật và chức năng đã làm cho các nhà lập trình mới hiểu được một cách dễ dàng solution nào đang được thực thi

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

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

Multiple Solutions

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

Thay vào đó, bạn phải sử dụng một script hiểu trật tự cần phải được built của các solution Một trong những nhiệm vụ bảo trì liên quan đến một kết cấu multiple-

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

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

Hình 3.3 Multiple Solution Approach

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

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

Xem xét các Dư án lớn

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

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

• Họ có nhiều khả năng hơn về quản lý các thành phần phụ thuộc trên các solutions

và các nhóm projects

• Họ có nhiều khả năng duy trì các thiết kế cho các thành phần và các nhóm

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

mở rộng giới hạn solution, hãy sử dụng phương pháp multiple solution

Tổng kết

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

Sử dụng một partitioned solution cho tập các nhóm project con mà một nhà lập trình

có thể chỉnh sửa nó như là một tập hợp, và sau đó tạo một master solution chứa tất

cả các project của bạn

Sử dụng multiple solutions để tạo một cái nhìn cụ thể trên những hệ thống con và

để giảm việc load và thời gian build của ứng dụng của bạn

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

Tài nguyên bổ sung

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

Chương 4 – Cấu trúc những Projects và Solutions trong Team Foundation Source Control

Chủ đề

• Cấu trúc dự án cho các nhóm phát triển phần mềm một cách hiệu quả trong

Microsoft® Visual Studio® Team Foundation Server (TFS) source control

• Làm cho cấu trúc thư mục server-side và client-side được đồng bộ hóa

• Chọn một chiến lược cho cấu trúc unit test

• Tạo một cấu trúc thư mục mà hỗ trợ các kịch bản branching khác nhau

• Tìm hiểu workspace là gì và làm thế nào mà nó có thể map các tập tin cục bộ vào source control

• Hiểu được những tập tin nào được thêm vào source control

Xem trước

Nhiều quy ước mặc định về thư mục được sử dụng bởi Visual Studio khi tạo mới những solution và project, chưa được tối ưu hóa cho các nhóm phát triển và việc sử dụng với TFS source control Thay vì chấp nhận các giá trị mặc định khi tạo mới các Visual Studio project và solution, bạn nên xem xét một cách cẩn thận đến cấu trúc thư mục cục bộ và cấu trúc thư mục trên server

Chương này bắt đầu bằng việc giải thích cho bạn nên kết cấu các solution và project trên máy tính của bạn (client-side) như thế nào và bạn nên kết cấu những thư mục của bạn với TFS source control (server-side) như thế nào Ngoài ra còn có các ví dụ

về những cấu trúc thư mục dành cho các loại ứng dụng khác nhau như là Microsoft Windows® Forms, smart clients, và các ứng dụng Web Sau đó, còn giải thích bằng cách nào mà workspace được sử dụng để quản lí mapping giữa client và những cấu trúc thư mục server

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

Sử dụng chương này để tìm hiểu các mẫu cấu trúc thư mục thích hợp cho các đội ngũ phát triển những dự án phức tạp và có kích cỡ khác nhau Để đạt được lợi ích lớn nhất từ chương này, bạn nên:

• Sử dụng cấu trúc server-side Sử dụng cấu trúc thư mục server-side để tổ chức

source code của project của bạn với TFS source control

• Sử dụng cấu trúc client-side Sử dụng cấu trúc thư mục client-side để tổ chức

source code của project của bạn trong workspace phát triển phần mềm cục bộ của bạn

ƒ Đọc các chủ đề Làm thế nào kèm theo Những đề tài này cung cấp các quy trình được thảo luận qua từng bước trong chương này:

• Làm thế nào: Tạo Source Tree của bạn trong Team Foundation Server

• Làm thế nào: Cấu trúc ASP.NET Applications trong Team Foundation Server

• Làm thế nào: Cấu trúc Windows Applications trong Team Foundation Server

• Làm thế nào: Cấu trúc những thư mục Source Control của bạn trong Team

Foundation Server

Cấu trúc Server-Side

Hầu hết các nhóm dự án chứa một hay nhiều Visual Studio solution, và mỗi solution

thì chứa một hay nhiều Visual Studio project Khi bạn yêu cầu phân nhánh để hỗ trợ

các hướng phát triển, bạn sử dụng một thư mục gốc tên là Main (trên cả client và

server) để nhóm các Visual Studio project của bạn lại với nhau Sau đây là một mẫu cấu trúc thư mục với TFS source control:

Main là thư mục chứa các source file và các thành phần liên quan như là build

output, tài liệu thiết kế, và các trường hợp kiểm thử Một thư mục ứng dụng (như là

MyApp1 trong thí dụ trước ) chứa tập tin Visual Studio solution (.sln) sử dụng để

nhóm một tập các Visual Studio project có liên quan lại với nhau Mỗi tập tin dự án

(.vcproj hay vbproj) được chứa trong một thư mục dành riêng cho dự án (dedicated

project folder), tại đường dẫn: /Main/Source/MyApp1/Source Các Unit tests (kiểm

thử đơn vị) mà đi kèm theo mỗi source project thì được chứa trong (hay ở bên dưới)

thư mục UnitTests Bạn có thể đặt thêm các file Visual Studio solution (.sln) trong thư mục Main để cho phép bạn làm việc với nhiều nhóm dự án khác nhau

Thư mục Docs và Test được sử dụng để chứa các thành phần phụ liên quen đến

nhóm dự án bao gồm có tài liệu về sản phẩm(product documentation) và các kiểm thử tự động (automated tests)

Thư mục TeamBuildTypes được tạo một cách tự động khi bạn tạo Team Build lần

đầu tiên Nếu bạn muốn kiểm tra bằng tay một loại team build, bạn có thể tạo thư mục này bằng tay, thêm các tập tin Team Build của bạn, và TFS chấp nhận thư mục này cho bạn một cách tự động

Để có thêm thông tin về những nhóm cấu trúc project và solution , hãy xem

―Chương 3 – Cấu trúc Projects và Solutions trong Source Control.‖

Lưu trữ các Unit Test

Bạn có thể lưu trữ các unit test dưới một thư mục tên là UnitTests tại cùng một cấp giống như là thư mục Source được nhìn thấy dưới đây:

Kịch bản này xử lý các unit test như là những thành phần ưu tiên nhất Tuy nhiên, tính tương thích giữa các nhánh ở mức độ project sẽ bị giảm đi Sau đây là một cấu trúc xen kẽ:

Sau đây là những lý lẽ tán thành và những lý lẽ phản đối khi áp dụng cho mỗi

phương pháp tiếp cận:

UnitTest như là một Peer với Source folder

• Tốt: Bạn có thể tìm thấy các unit tests tại cùng một vị trí

• Tốt: Bạn phân chia các shipping code từ các non-shipping code

• Tốt: Tiến trình thiết kế của bạn có thể dễ dàng chạy tất cả các unit test trên tất cả các project

• Khó khăn: Các nhà lập trình sẽ khó khăn khi chạy các unit test cho các project của

họ

• Khó khăn: Khi bạn phân nhánh source, nó sẽ không bao gồm các unit tests

UnitTests trong mỗi Project

• Tốt: Các nhà lập trình có thể chạy dễ dàng các unit test trên một project đơn

• Tốt: Khi bạn phân nhánh, những thư mục được phân nhánh của bạn bao gồm các unit test, vì thế chúng có thể ở tại các biên liên kết chặt chẽ đến phần source trong mỗi nhánh

• Khó khăn: Bạn hòa trộn shipping với non-shipping code trong thư mục source

• Khó khăn: Thường thì bạn sẽ gặp khó khăn hơn trong việc chạy tất cả các unit test cùng một lúc vào lúc build trên tất cả các project

Lưu trữ các tài liệu

Thư mục Documentation là những tài liệu hướng dẫn liên quan đến sản phẩm Để

giúp định nghĩa những tài liệu gì được lưu trữ trong TFS source control và cái gì lưu trữ trong một thư viện tài liệu trên trang Microsoft Windows SharePoint® team của bạn, hãy xem các bước sau:

• Sử dụng SharePoint dành cho tài liệu nội bộ của nhóm ví dụ như là use cases, scenario(kịch bản) và tài liệu về các yêu cầu, và tài liệu thiết kế

• Sử dụng TFS source control cho các tài liệu hướng dẫn liên quan đến sản phẩm

mà bạn chuyển đến cho các khách hàng của bạn.Điều này có thể bao gồm việc cài đặt và triển khai các hướng dẫn, các hoạt động hướng dẫn, và các tập tin Help Hầu hết các tài liệu là các tập tin binary file, vì thế hãy xem xét việc sử dụng các exclusive lock để tránh phải thực hiện merging bằng tay Bằng cách làm như vậy, bạn sẽ nhận được các thông báo khi một file đang được sử dụng và giúp tránh được việc phải thực hiện merging một cách thủ công

Sử dụng một cách thận trọng khi sử dụng SharePoint vì việc quản lý các phiên bản của tài liệu được yêu cầu nghiêm ngặt So với TFS source control, thì việc thay đổi

đè lên trong SharePoint dễ dàng hơn Mặc định, SharePoint cho phép tùy chọn

"overwrite existing file" (chép đè lên các file đã tồn tại) được chọn khi các file đã được tải lên

Cấu trúc Client-Side

Cấu trúc thư mục cục bộ trên development workstations của bạn nên được đồng nhất với cấu trúc thư mục server Giữ các thành phần source được tổ chức tốt trên workstation của bạn bằng cách đặt tất cả các source từ tất cả các nhóm project lại với nhau dưới một thư mục gốc, như là C:\DevProjects Hãy tạo một thư mục con cho mỗi team project như bạn thấy trong thí dụ này:

C:\DevProjects Thư mục gốc chứa tất cả các team projects

Bên dưới mỗi team project folder, sử dụng một cấu trúc sao chép của thư mục ứng dụng được sử dụng trên source control server như là thí dụ dưới đây: