如何在TFS中為發布管理提供xml / json配置

Question

我在內部前提Team Foundation Server 2015更新3中有一個發布版本定義，這是發布管理的新的基於Web的版本。 這利用了由多個部署所需的服務組成的工件。 我們有一個Powershell腳本，可用於部署所有服務並正確配置環境。

針說，每個環境都是不同的（不同的數據庫，不同的配置）。 用於部署的Powershell腳本需要一些配置，這些配置不容易通過版本管理中的“變量”選項卡作為純變量插入（由於對象/數組）。 我們想使用json / xml文件作為配置的Powershell腳本的輸入。

我的問題是，我們如何才能針對不同的環境（也用於生產環境）管理這些json / xml文件，並使它們僅可用於TFS中與之對應的平台？ 這不會使環境能夠訪問/查看不是它們自己的配置文件。 同樣，在沒有將配置作為代碼一部分的情況下，所有開發人員都可以使用該配置，這也不是所希望的。

Answer 1

我們將每個零件存儲在不同的工件中，因此對您來說，根據您的工作方式，CI 可能會生成一個主要的“構建”工件，然后是一系列的“ dev”，“ smoke test”，“ qa”，“ pre-活動”，“生產”（或您為它們命名）工件（可能只是配置文件等）。

部署構建時，可以使用“獲取工件”任務來獲取主構建以及適用於您所處環境的適當配置。 抱歉，我是個小矮人，這是我們在內部編寫的任務，我用得太多了才注意到它不是內置的。

我們以幾種不同的方式來解決這個問題。

一個（或多個）XML / JSON“轉換”文件可用於更新默認配置（例如用於轉換app.config並根據需要更新連接字符串），我們將這種方法與變量/參數一起使用從構建中傳入，因此我們實際上是在告訴PowerShell腳本使用一組特定的轉換。

您可以做的是讓CI生成構件，並分別放入配置中，這樣您就可以維護它們而無需依賴任何怪異的轉換。 您可以使用帶有適當過濾器的“復制和發布構建工件”任務，為您的應用生成一個工件，為您的開發配置生成一個工件，為qa配置生成一個工件。

在某些情況下，如果您需要生成不同的軟件包（用於部署到雲服務等），則可以重新運行編譯步驟並將整個事物/軟件包放入工件中，因此您將擁有artifact_dev和artifact_qa ...只要如果您使用相同的CI生成它們，則應該能夠將它們放在發行版的工件暫存目錄中（我相信）。 然后，您的PowerShell進入articleStaging / {environment}。