我在Team Foundation Server 2015更新3中有一个发布版本定义，这是基于Web的新版本的发布管理。这使用了由部署所需的多个服务组成的工件。我们有一个Powershell脚本，用于部署所有服务并正确配置环境。
需要说的是，每个环境都不同（不同的数据库，不同的配置）。用于部署的Powershell脚本需要一些配置，这些配置不容易通过发布管理中的变量选项卡作为普通变量插入（因为对象/数组）。我们希望将json / xml文件用作配置，作为用于部署的Powershell脚本的输入。我的问题是，我们如何为不同的环境（也用于生产）管理这些json / xml文件，并且能够仅在TFS中对应的平台上访问它们？这使得环境无法访问/查看不属于自己的配置文件。此外，没有配置是代码的一部分，并且所有开发人员都可以使用它，这也是不可取的。
答案 0 :(得分：0)
我们将每个部分存储在不同的工件中，因此对于您来说，根据您的工作方式，您可以 让CI生成主要的“构建”工件，然后是一系列“dev”，“smoke”测试“，”qa“，”pre-live“，”production“（或者你命名它们）工件（可能只是配置文件等）。
部署构建时，可以使用“获取工件”任务来获取主构建，并为您正在使用的环境进行适当的配置。抱歉，我是一个numpty，这是我们内部编写的一项任务，我只是太过注意它没有内置。
我们以几种不同的方式处理这个问题。
一个（或多个）XML / JSON“转换”可用于更新默认配置的文件（例如一个转换app.config并根据需要更新连接字符串），我们使用此方法从构建传入的变量/参数，因此我们基本上告诉PowerShell脚本使用一组特定的变换。
你可以做的是让你的CI产生一个工件，再加上单独的配置，这样你就可以维护它们而不依赖任何奇怪的变换。您可以使用适当的过滤器使用“复制和发布构建工件”任务，并为您的应用程序生成一个工件，一个用于您的开发配置，一个用于qa配置等。
在某些情况下，如果您需要生成不同的包（用于部署到云服务等），您可以重新运行编译步骤并将整个事件/包放入工件中，因此您将拥有artifact_dev和artifact_qa ...只要您从相同的CI生成它们，您就应该能够在发布的工件暂存目录（我相信）中获取它们。然后你的PowerShell进入artifactStaging / {environment}。