我是CI / CD世界的新手，现在我想在我的开发过程中实现这些工作流程。 我想了解当Dev，Test和Prod有轻微差异时，如何正确地构建和发布管道以管理Dev，Test和Prod环境。
所以我正在制作一个Asp .Net Core应用程序，代码托管在Azure DevOps中，我也将用于构建和发布，对于客户端代码（js和css）我使用Typescript和SASS并编译为js和css我使用npm脚本。
现在在Dev环境中我想部署非缩小的js和css，我也想要源映射文件，在Test环境中我想要缩小的js和css以及sourcemap文件，在prod环境中我只想要缩小版本我的css和js。
这个案例仅作为实际例子，但我想了解一般规则，无论应用程序类型，主机，构建和发布平台如何，我都可以应用。 作为一个额外的说明，我理解这个案例非常简单，可以很容易地管理而不需要太多的仪式，但我想了解指南和最佳实践，然后我将选择适合我的特定情况并适应这些指导方针和最佳做法。
现在我可以选择不同的选项：
我不喜欢选项1.1，因为我不喜欢遍布整个地方的无用文件，这会在构建管道中添加一些不必要的额外步骤。
选项1.2和1.3为构建管道增加了一些复杂性。
使用选项2.x，我们有“不完整”的构建，因为构建过程产生的工件缺少部署环境所需的一些工件。
对我而言，我不知道CI和CD工作流程的准则和最佳实践是什么，似乎更合适的是选项1.3或2.3之一。
如果我现在没错，问题就变成了： 可以使用构建管道来生成不完全可交付的工件，因为它们不符合部署环境的要求（比如需要在Dev环境中拥有源映射）？
你好莱尼，
我多年来一直担任发布经理，我理解你的痛苦。在我使用的系统中，序列是这样的：1：从开发域到登台服务器2：从登台服务器到渗透和漏洞测试环境3：从测试域到SaaS生产域和DML存储库。 4：从生产域到托管和安装剪切。
我的建议是，所有整理，例如删除开发人员的备份例程（按照严格的约定命名）和缩小是在登台服务器上完成的。我们允许将小错误修复应用于登台服务器代码，然后“修复包”发布版本。一旦代码进入渗透和漏洞测试环境，我们的做法是代码本身不得更改：只有域之间的安全设置和托管/安装版本。
一旦有文件化的流程达成一致，人们就可以很容易地将其用作检查表。您的流程可能需要与我上面列出的流程不同，并且应该预期它们会随着时间的推移而得到改进。我知道很多人不喜欢文件化的程序，但我在这里记录了一些好处：http://www.esm.solutions/wp/change-management/
罗伯特，很快见到你