可以說是第2步每晚不是構建定義,它是一個控制檯應用程序:
- 獲取最新的接連的建立
- 抓鬥此版本的二進制文件從生成放置位置
- 根據他們是否成功執行測試&,執行某些操作(如發送電子郵件或在源代碼管理中應用標籤)。
這些動作也可以在一個高度定製生成過程模板,其中相同CreateWorkspace和運行的MSBuild主要構建步驟砍掉&上述邏輯是由手工實現製造。
在你的地方,我會去使用TFS-SDK的C#控制檯應用程序,上面的&是否計劃每天進行一次。
編輯
考慮您的意見考慮在內,我不明白爲什麼我的建議是從您的構建流水線帶你走。
在任何情況下,Step2的心臟(至少在我的理解中)是檢索先前成功構建的放置位置,然後對位於那裏的二進制文件執行一些操作。
這檢索可能類似於以下內容:
using System;
using Microsoft.TeamFoundation.Build.Client;
using Microsoft.TeamFoundation.Client;
namespace GetDropLocationOfLastGoodBuild
{
class Program
{
static void Main()
{
TfsTeamProjectCollection tpc =
TfsTeamProjectCollectionFactory.GetTeamProjectCollection(
new Uri("TFSURI"));
IBuildServer buildService = (IBuildServer) tpc.GetService(typeof (IBuildServer));
IBuildDefinition buildDefinition = buildService.GetBuildDefinition("TeamProject", "BuildDefinitionName");
Uri buildUri = buildDefinition.LastGoodBuildUri;
IBuildDetail buildDetail = buildService.GetAllBuildDetails(buildUri);
String binariesOfLastGoodBuild = buildDetail.DropLocation;
}
}
}
已經檢索到的放置位置,你應該能夠開始你有計劃的任何活動。
您需要的所有細節都在buildDetail
。
現在,這可以作爲高度自定義構建過程模板的自定義構建活動來運行,也可以作爲單獨的計劃控制檯應用程序運行。
個人我會做後者&將它設置爲Windows任務計劃程序在我的buildserver每天執行一次。
僅供參考,如果基於配置的構建之間存在顯着差異,則此類事情將不起作用。例如,使用web.config轉換Web應用程序,您希望構建不同的配置,因爲它們會產生不同的配置設置。 –
另外,你的CI構建和你的發佈版本之間是否真的有一對一的映射?通常,「n」CI構建最終會生成「m」版本,用於產生「1」版本的QA。 –
因爲這個原因,我們不使用web.config轉換。配置在打包應用程序或安裝時發生。關於管道的想法,它當然不是1-1映射。我試圖實現的是,我測試的dev,devtest,qa等二進制文件也是使用或發送給用戶的二進制文件。這樣,我可以自信地說,發行包和這些確切的二進制文件都是睾丸。由於TFS的性質,大多數使用的範例似乎是在構建管道的每個步驟/階段進行編譯。 – jaspernygaard