北京软件公司采用的连续交付是一种软件开发规程，软件始终保持可释放性。这些文献包含了如何采用持续交付的说明，但在实践中采用是一个挑战。我们选择了其中几个进行进一步分析，基于它们包含采用持续交付的经验证据，并专注于实践而不仅仅是模具。我们定性分析了选定的文章，并提出了问题，原因和解决方案。问题和解决方案主题合成为七个主题：构建设计，系统设计，集成，测试，发布，人力和组织与资源。
软件开发中集成问题

问题	描述
大提交	提交包含大量更改。
合并冲突	将更改合并显示更改之间的冲突。
破碎的建造	建筑物长时间断裂或经常断裂。
工作堵塞	完成工作任务由于队列中的构建或其他集成被破坏或阻止。
长跑分支	代码在分支机构开发，持续时间长。
破碎的开发流程	开发人员分心，发展的流程突破。
缓慢整合批准	更改被批准缓慢的主线。

整合主题涵盖了将源代码整合到主线中时出现的问题。这个主题的问题在表8中有描述。
这个主题中的所有代码都通过报告的因果关系进行连接，见图。6。有些人试图避免分支的整合问题，但长期以来，实际上提到了长期的分支机构，使整合更加麻烦：
随着主要代码基础的发展，分支机构进一步远离干线，使得分支机构较终并入后备箱变得越来越痛苦和复杂。
报告了集成问题与相关测试问题之间的因果关系。
图选项
集成主题中的另一个有趣的特征是代码破坏，工作阻塞和合并冲突之间的恶性循环。情况强调：一旦构建中断，团队就会遇到一种“停电”。修复时间越长，修改越困难，将更改合并在一起。很多时候，这种合并的努力导致进一步的构建中断等等。
大提交
较大的提交是有问题的，因为它们包含多个可能与其他变更相冲突的更改：
这些较大的更改集意味着在完成登记之前需要更多的文件合并，进一步延长提交所需的时间。
然而，北京软件公司开发人员大量提交的原因有很多：耗时的测试，大功能，网络延迟和缓慢的集成审批流程。因此，为了处理大的事情，必须考虑到这些根本原因。
合并冲突
合并冲突发生在不同开发者所做的更改冲突时。解决这样的冲突可以付出巨大的努力：
我们感觉到长时间运行的分支机构合并了太多次的痛苦。合并冲突可能需要几个小时才能解决，而且很容易意外中断代码库。
合并冲突可能由长时间运行的分支或大提交引起。延迟执行过程，如冗长的代码审查也可能导致合并冲突[C21]。在某些情况下，合并冲突可能更少：如果软件开发人员在源代码的不同部分工作，或者有少量软件开发人员。