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