Đâ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 .
- 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 server.
- 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 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 server.
• 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
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 server.
Build ngay lập tức ngay sau khi mọi check-in là chiến 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
build server của bạn, thì bạn nên sử dụng một phương pháp rolling build 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 quá trình xảy ra các check-in 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 "Chương 8 - Thiết lập một Continuous Integration Build 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.
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
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
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
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
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
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
• Để 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
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
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.
