北京軟件公司採用的連續交付是一種軟件開發規程，軟件始終保持可釋放性。這些文獻包含瞭如何採用持續交付的說明，但在實踐中採用是一個挑戰。我們選擇瞭其中幾個進行進一步分析，基於它們包含採用持續交付的經驗證據，並專注於實踐而不僅僅是模具。我們定性分析瞭選定的文章，並提出瞭問題，原因和解決方案。問題和解決方案主題合成爲七個主題：構建設計，系統設計，集成，測試，發布，人力和組織與資源。
軟件開發中集成問題

問題	描述
大提交	提交包含大量更改。
合並沖突	将更改合並顯示更改之間的沖突。
破碎的建造	建築物長時間斷裂或經常斷裂。
工作堵塞	完成工作任務由於隊列中的構建或其他集成被破壞或阻止。
長跑分支	代碼在分支機構開發，持續時間長。
破碎的開發流程	開發人員分心，發展的流程突破。
緩慢整合批準	更改被批準緩慢的主線。

整合主題涵蓋瞭将源代碼整合到主線中時出現的問題。這個主題的問題在表8中有描述。
這個主題中的所有代碼都通過報告的因果關系進行連接，見圖。6。有些人試圖避免分支的整合問題，但長期以來，實際上提到瞭長期的分支機構，使整合更加麻煩：
随著主要代碼基礎的發展，分支機構進一步遠離幹線，使得分支機構較終並入後備箱變得越來越痛苦和複雜。
報告瞭集成問題與相關測試問題之間的因果關系。
圖選項
集成主題中的另一個有趣的特征是代碼破壞，工作阻塞和合並沖突之間的惡性循環。情況強調：一旦構建中斷，團隊就會遇到一種“停電”。修複時間越長，修改越困難，将更改合並在一起。很多時候，這種合並的努力導緻進一步的構建中斷等等。
大提交
較大的提交是有問題的，因爲它們包含多個可能與其他變更相沖突的更改：
這些較大的更改集意味著在完成登記之前需要更多的文件合並，進一步延長提交所需的時間。
然而，北京軟件公司開發人員大量提交的原因有很多：耗時的測試，大功能，網絡延遲和緩慢的集成審批流程。因此，爲瞭處理大的事情，必須考慮到這些根本原因。
合並沖突
合並沖突發生在不同開發者所做的更改沖突時。解決這樣的沖突可以付出巨大的努力：
我們感覺到長時間運行的分支機構合並瞭太多次的痛苦。合並沖突可能需要幾個小時才能解決，而且很容易意外中斷代碼庫。
合並沖突可能由長時間運行的分支或大提交引起。延遲執行過程，如冗長的代碼審查也可能導緻合並沖突[C21]。在某些情況下，合並沖突可能更少：如果軟件開發人員在源代碼的不同部分工作，或者有少量軟件開發人員。