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