我的公司正在使用 Jenkins 进行持续集成，我正在尝试转向 CD。我正在使用 git hub 作为代码存储库。现在我们正在将特性分支合并到一个 uat 环境中，当一个特定的特性被接受时，特性分支将被合并到我们的生产分支中。这显然很危险，因为可以同时测试两个更改并分别部署。理想情况下，我们会在不重建的情况下测试和部署一个包，但我很难看到这是怎么可能的。如果两个人在两个不同的功能上工作，第一个完成，打包并进入测试，第二个完成并打包没有第一个？但是，我怎样才能在不使其他功能的测试失效的情况下部署包呢？我'
任何帮助将不胜感激。
此外，如果您查看http://ptgmedia.pearsoncmg.com/images/chap5_9780321601919/elementLinks/fig5_6.jpg 我担心的是签入 1 在通过验收测试时可以部署并且该包将被部署，但是什么如果验收测试失败？签入 5 包含与签入 1 相同的问题，因此在签入 1 修复或删除之前无法部署到生产环境。删除更改会很烦人，因为可能需要删除多个提交，并且修复 + 测试可能需要很长时间。
持续交付是持续集成的延伸。CI 就是经常在其他人的背景下评估你的更改（如果你每天提交的次数少于一次，则不能算作 CI）
任何形式的分支都是为了隔离变化，因此从根本上与 CI 不一致。特征分支和 CI 是对立的。
大多数组织所做的是在测试之前合并分支。这损害了特征分支的价值，但保留了 CI 的价值。如果您不这样做，那么由于您描述的原因，CI 几乎没有真正的价值 - 您没有在现实环境中评估更改。
对不起，你不能两者兼得，它们是相反的！
如果你想做持续交付，那么分支是不行的。嗯，大部分。版本应该在 SCM 中标记，应用到版本的修复并合并回 HEAD。
您还应该进行自动化测试来证明该修复程序确实解决了问题。在某些情况下，这可能很难。在这种情况下，您应该做的最低限度是验证修复不会破坏现有行为（如果这是修复的目的）。
功能切换很好，抽象分支也很好，但在实践中，只有采用 CD 的最成熟和有经验的团队才会采用这种方式。我怀疑你还没有到那个时候，所以这将帮助你克服你的障碍，直到你对 CD 更舒服。
如果要同时部署两个特性，那么我想你应该使用 TDD 原则，先创建一个 FAILING 测试，然后实现代码使其变绿。签入该测试，因此在您实施之前，任何构建都无法继续进行。这将清楚地表明此构建不是用于生产的，因为该功能不完整。将此测试作为 CI 不是一个好主意，但在测试的最新阶段......前提是您有多个测试阶段！
关于修补程序的周期时间与不太重要的事情的差异，您是否研究过功能切换？http://martinfowler.com/bliki/FeatureToggle.html
