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
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
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
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
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
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
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:
<Mappings>
<InternalMapping ServerItem="$/MyTeamProject"
LocalItem="c:\projects\teamproject"
Type="Map" />
<InternalMapping ServerItem="$/MyTeamProject/documentation"
Type="Cloak"
/>
</Mappings>
Tài nguyên
bổ sung
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
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
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
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
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
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
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:
<!-- Create
WorkItem for build failure -->
<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
Build Resources
