问题描述
在TFS 2018中遇到了一个问题，他的应用程序包含一个ASP.NET Core后端和一个React前端（纯静态）。他们已经创建了一个构建流程，包括从代码库获取源代码、获取NuGet包（后端）、构建后端、运行后端测试、获取NPM包（前端）、构建前端、运行前端测试、生成和发布构建产物等步骤。然后，一个发布流程会获取这些构建产物并将它们部署到Azure AppService（后端）和Azure Storage v2账户（前端）。目前只有一个环境，但他们需要支持多个环境。问题在于前端构建依赖于一些环境变量，在构建阶段时这些变量尚不存在，因为构建尚不知道将要部署到哪个环境。
他列举了一些选项：
1. 在发布流程中生成前端构建。这需要一种方式让发布流程能够获取到源代码，可以通过Git或从构建产物中获取。但由于npm_modules非常庞大，后者的速度较慢。
2. 构建应该为所有可能的环境生成构建产物，然后每个发布环境都会选择合适的构建产物。
用户希望了解在TFS 2018中如何处理这个问题，以及推荐的方法是什么。
解决方案
请注意以下操作可能受版本差异影响，建议在操作前备份数据。
方案1：发布流程中生成前端构建
在使用Azure CI/CD产品族时，通常会创建一个发布产物，然后使用发布流程将同一产物发布到不同的环境。这是一种典型的最佳实践，也是“企业”级发布管理流程的期望。云原生应用的一般原则是“构建一次，多次部署，通过环境变量配置”。令人惊讶的是，在React社区中似乎并不熟悉这种最佳实践，所以你需要在各种解决方案中寻找。
在上面提到的链接中，有一位用户分享了在他们的案例中的解决方法，他们不想让React应用的部署与后端微服务不同，而是希望实现“构建一次，在任何地方运行”。因此，他们更改了前端代码，使其在页面加载时从服务器获取环境变量。这样的做法结合使用容器，可以确保在任何地方都始终运行相同的前端库，即使前端构建工具在使用相同的依赖项时配置不当或存在错误。
在你的情况下，你确实有一个发布流程，可以使用与构建流程相同的内置和市场任务。这意味着向发布流程中添加一个前端编译任务是直接的。
方案2：为所有环境生成构建产物
另一个方法是为所有可能的环境生成前端构建产物，然后每个发布环境会选择适当的构建产物。这样做的好处是能够在发布时选择最适合特定环境的构建产物，但也会产生一些额外的工作。
你可以使用以下步骤来实现：
1. 针对每个目标环境，创建一个特定的前端构建配置文件，例如config.production.js和config.staging.js。
2. 在构建流程中，根据目标环境的不同，使用适当的配置文件来构建前端代码。
3. 在发布流程中，选择与目标环境匹配的前端构建产物。
请注意，这种方法需要维护多个不同的构建配置，并确保构建流程能够正确地使用适当的配置文件来生成构建产物。
注意事项
不论选择哪种方法，你都需要确保前端构建能够稳定地生成相同的依赖版本，以避免构建之间的差异。对于npm包的稳定性，你可以考虑使用一些工具，例如yarn，以确保在每次构建中使用相同的依赖版本。
总结
在TFS 2018中处理多个构建环境的问题，你可以考虑在发布流程中生成前端构建，或者为所有可能的环境生成构建产物。前者需要在页面加载时从服务器获取环境变量，而后者需要维护多个不同的构建配置文件。无论选择哪种方法，都需要确保前端构建稳定并使用相同的依赖版本。根据你的实际需求和流程，选择最适合你团队的方法。