我在TeamFoundationServer2015update3内部部署中有一个版本构建定义，它是新的基于web的版本管理。这就利用了一个工件，该工件由需要部署的多个服务组成。我们有一个Powershell脚本，用于部署所有服务并正确配置环境。
需要说的是，每个环境都是不同的(不同的数据库，不同的配置)。用于部署的Powershell脚本需要一些配置，这些配置不容易通过发布管理中的变量选项卡作为普通变量插入(因为对象/数组)。我们希望使用json/xml文件进行配置，作为用于部署的Powershell脚本的输入。
我的问题是，我们如何为不同的环境(也为生产环境)管理这些json/xml文件，并使它们只能由TFS中对应的平台访问？这不会使环境能够访问/查看非其自身的配置文件。此外，如果没有将配置作为代码的一部分，并且所有开发人员都可以使用，这也是不可取的。
我们将每个部分存储在不同的工件中，因此对您来说，根据您的工作方式，可以让CI生成一个主要的"构建"工件，然后是一系列的"dev"、"smo-test"、"qa"、"pre-live"、"production"(或您如何命名它们)工件(可能只是配置文件等)。
我们用几种不同的方式来处理这个问题。
一个(或多个)XML/JONS"转换"文件，您可以使用它来更新默认配置(例如根据需要转换app.config和更新连接字符串的文件)，我们将这种方法与从构建中传入的变量/参数一起使用，因此我们本质上是告诉PowerShell脚本使用一组特定的转换。
你可以做的是让你的CI生成一个工件，再加上单独放入配置，这样你就可以在不依赖任何奇怪的转换的情况下维护它们。您可以使用带有适当过滤器的"复制和发布构建工件"任务，并为您的应用程序生成一个工件，为您的dev-config生成一个，为qa-config等生成一个。
在某些情况下，如果你需要生成不同的包(用于部署到云服务等)，你可以重新运行编译步骤，并将整个东西/包放入一个工件中，这样你就有了artifact_dev和artifact_qa。。。只要您从同一个CI生成它们，就应该能够将它们放在发布的工件暂存目录中(我相信)。然后您的PowerShell将进入artifactStaging/｛environment｝。