我是CI / CD领域的新手，现在我想在开发过程中实现这些工作流程。
我想了解当开发，测试和产品有细微差别时，如何正确构建和发布管道来管理开发，测试和产品环境。
因此，我正在制作一个Asp .Net Core应用程序，该代码托管在Azure DevOps中，我还将用它来构建和发布，对于客户端代码（js和css），我使用Typescript和SASS进行编译js和CSS，我使用npm脚本。
现在在开发环境中，我想部署非最小化的js和css，并且我还想要sourcemap文件，而在测试环境中，我想要缩小的js和css和sourcemap文件，在产品环境中，我只想要我的CSS和JS的缩小版本。
此案例仅作为实际示例，但我想了解一般规则，无论应用程序类型或主机，构建和发布平台的种类如何，我都可以应用该规则。
另外请注意，我知道此案例非常简单，无需过多的仪式即可轻松进行管理，但是我想了解指导原则和最佳做法，然后我将选择适合于我的特定案例并适应的案例这些准则和最佳做法。
现在我可以在不同的选项之间进行选择：
我不喜欢选项1.1，因为我不希望将无用的文件散布到各处，这会在构建管道中添加一些不必要的额外步骤。
选项1.2和1.3给构建管道增加了一些复杂性。
使用选项2.x，我们具有“不完整”的构建，因为构建过程产生的工件缺少部署环境所需的某些工件。
对我来说，我不知道CI和CD工作流程的指导方针和最佳实践是什么，似乎更合适的选择是1.3或2.3。
如果我现在没记错，问题将变为：
可以接受具有生成不完全可移植的工件的构建管道，因为它们不满足部署环境的要求（例如在Dev环境中具有Sourcemap的需求）？
答案 0 :(得分：0)
Ciao Leoni，
我已经担任发布经理很多年了，我了解您的痛苦。在系统中，我处理序列的过程是这样的： 1：从开发域到登台服务器 2：从登台服务器到渗透和漏洞测试环境 3：从测试域到SaaS生产域和DML存储库。 4：从生产域到托管和安装剪辑。
我的建议是，所有整理工作（例如删除开发人员的备份例程（按照严格的约定命名）和最小化）均在登台服务器上完成。我们允许将较小的错误修复程序应用于登台服务器代码，然后剪切“修订包”版本。一旦代码进入渗透和漏洞测试环境，我们的实践便是代码本身不得更改：仅更改域之间以及托管/已安装版本的安全设置。
一旦同意了文档化的流程，人们很容易将其用作检查表。您的流程可能需要与我上面概述的流程有所不同，并且应该随着时间的推移不断完善它们。我知道许多人不喜欢记录在案的程序，但是我在这里记录了一些好处： http://www.esm.solutions/wp/change-management/
罗伯特·普雷斯托，