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

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

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