问题描述
一个大型公司正在考虑为混合移动应用程序开设第二条流水线，以便将热修复直接发布到生产环境。有人认为这可能存在问题，认为更好的做法是更多地关注前移、改善代码质量/测试，并通过特性标志隐藏尚未准备好的代码/功能。这样可以保持单一的流水线，使得发布特性与热修复的过程保持一致。
他们对这种方法的担忧在于，即使隐藏了一半完成的代码（特性），将其发布到生产环境中可能会导致法律责任或误解，从而引发负面的舆情。有人提出，我们应该通过编译过程来确保特性标志能够阻止代码进入生产版本的应用程序。
问题是，其他有实际经验的务实人士在大型公司（约1万名员工）中是否使用第二条流水线？如果不使用第二条流水线，有哪些最佳实践可以为变革提供有力的证据（我尝试过查阅《DevOps手册》和一些谷歌搜索，但没有找到权威的陈述）？
解决方案
请注意以下操作可能因版本差异而有所不同，始终谨慎操作。
最佳实践：统一流水线，依赖特性标志
在许多情况下，维护单一的流水线，并通过特性标志来管理特性的发布和热修复是一个较为理想的方法。这种方法可以降低复杂性，并避免将不完整的代码发布到生产环境中。以下是如何实施的建议步骤：
特性标志： 采用特性标志来隐藏尚未准备好的特性。这意味着即使特性的代码已经合并到主分支，但只有当特性标志打开时，特性才会在应用程序中可见。
持续集成和持续交付： 维护一个统一的持续集成（CI）和持续交付（CD）流水线。无论是特性发布还是热修复，都经过相同的构建、测试和部署流程。这将确保代码的一致性和稳定性。
分支管理： 如果遇到安全漏洞（如CVE）等紧急问题，可以在主分支上创建一个紧急修复分支，该分支只包含必要的修复。修复后，将该分支合并回主分支，确保所有版本都包含修复。
小批量发布： 将代码和特性拆分为小批量，经常进行部署。这可以减少待发布的代码量，更容易管理和测试。
监控和回滚： 实施强大的监控机制，以便在任何异常情况下迅速回滚更改。及时了解生产环境中的问题，并快速采取措施。
考虑的因素
在采用统一流水线和特性标志的方法时，有一些考虑因素需要注意：
- 特性标志的管理： 特性标志应该由团队统一管理，确保在需要时可以轻松地开启或关闭特性。
- 安全性和风险： 在发布未完成的特性时，确保其不会引发严重的安全隐患。对于CVE等安全问题，确保紧急修复分支的代码已经经过充分测试。
- 文化和流程： 引入新的流程和文化可能需要一些时间和培训，确保团队成员充分理解和遵守。
借鉴实践经验
对于在大型公司中是否使用第二条流水线，实践经验因公司和项目而异。一些公司可能会选择使用第二条流水线来快速响应热修复，但这也可能增加了维护的复杂性。最好的做法是通过参考类似规模和行业的公司的经验，了解他们是如何管理流水线和发布过程的。
评论1：非常感谢您的回答。构建和部署流水线是相同的，即将代码提交到仓库的测试分支，然后进行构建和部署到测试环境。预发布和生产环境也是如此。我们遇到的问题是，如果我们的依赖项中出现CVE，但我们正在进行一些特性添加，该如何将该修复排在队列的前面，同时又不会过早地发布所有未完成的内容。2. 最理想的答案是分批次工作并进行更频繁的部署。这样，您可以更快地响应像CVE这样的问题，而无需加快修复的速度。否则，您必须采取代表“当前已发布内容”的分支来进行修复，并确保它被合并到其他分支中（听起来还不错，但可能会变得混乱）。
结论
对于在生产中实施多条流水线的最佳实践，将流程简化并依赖特性标志来管理特性发布和热修复是一种较为务实的方法。通过保持统一的CI/CD流