我想了解一些与我最近的经历有关的情况。
在我目前的项目中，我们使用相同的设置，Angular-cli来构建生产就绪的捆绑包，使用teamcity来执行这些命令，使用Octopus Deploy来分发包。 但是我们遇到了为不同环境部署的一些问题。
我们的Azure上有4个环境：开发，测试，登台和制作。 我们希望每当我们的主分支被推送时，TeamCity构建应用程序，通过自动部署到开发将其推送到章鱼，并通过Octopus webapp将其推广到其他环境。
我们在Azure上有后端的4个环境，每个环境都有自己的IP地址。
从Angular角度来看，这种方法非常简洁，但Teamcity完全没有 - ＆gt;八达通，适用于所有环境的单一包装。
在这种方法中，我们有不同的environement.ts文件，其中包含我们服务使用的已配置的API端点。
在每次推送时，我们的Teamcity为每个环境执行ng构建，为该构建创建一个包并将其推送到章鱼。因此，章鱼为每个构建获得4个包，它可以部署到Azure上的正确环境。
从角度来看，这很有效，本地开发人员在提交代码之前不必进行任何本地更改+端点在部署包中被烘焙。
但是来自Teamcity - ＆gt;八达通的观点并不干净，这些平台的组合使得Teamcity每个代码推送产生一个包，然后Octopus将该包（并针对不同的环境进行一些具有变量的文件转换）部署到不同的环境。
第二种方法对Teamcity有利 - ＆gt;八达通部分。 在我们的Angular App中，我们编写了一个服务，用于从/ assets文件夹中的.json文件获取API端点等应用程序设置。
这种方法很棒，因为Teamcity可以构建1个包，然后Octopus可以从包的资产中操作.json文件。
但是，由于我们正在执行http请求以获取应用程序设置，因此这种方法并非完全无声，而我们认为应该在应用程序中烘焙这些内容。
我想对这些方法有所了解，因为我不是Angular-Teamcity-Octopus组合的专业人士，我想知道是否有人遇到过这种情况，以及是什么“银弹”＆＃39;可能是。