北京軟件公司采用的連續(xù)交付是一種軟件開發(fā)規(guī)程,軟件始終保持可釋放性。這些文獻包含了如何采用持續(xù)交付的說明,但在實踐中采用是一個挑戰(zhàn)。我們選擇了其中幾個進行進一步分析,基于它們包含采用持續(xù)交付的經(jīng)驗證據(jù),并專注于實踐而不僅僅是模具。我們定性分析了選定的文章,并提出了問題,原因和解決方案。
問題和解決方案主題合成為七個主題:構建設計,系統(tǒng)設計,集成,測試,發(fā)布,人力和組織與資源。
問題和解決方案主題合成為七個主題:構建設計,系統(tǒng)設計,集成,測試,發(fā)布,人力和組織與資源。
軟件開發(fā)中集成問題
問題 描述
大提交 提交包含大量更改。
合并沖突 將更改合并顯示更改之間的沖突。
破碎的建造 建筑物長時間斷裂或經(jīng)常斷裂。
工作堵塞 完成工作任務由于隊列中的構建或其他集成被破壞或阻止。
長跑分支 代碼在分支機構開發(fā),持續(xù)時間長。
破碎的開發(fā)流程 開發(fā)人員分心,發(fā)展的流程突破。
緩慢整合批準 更改被批準緩慢的主線。 整合主題涵蓋了將源代碼整合到主線中時出現(xiàn)的問題。這個主題的問題在表8中有描述。
這個主題中的所有代碼都通過報告的因果關系進行連接,見圖。6。有些人試圖避免分支的整合問題,但長期以來,實際上提到了長期的分支機構,使整合更加麻煩:
隨著主要代碼基礎的發(fā)展,分支機構進一步遠離干線,使得分支機構終并入后備箱變得越來越痛苦和復雜。
報告了集成問題與相關測試問題之間的因果關系。
圖選項
集成主題中的另一個有趣的特征是代碼破壞,工作阻塞和合并沖突之間的惡性循環(huán)。情況強調(diào):一旦構建中斷,團隊就會遇到一種“停電”。修復時間越長,修改越困難,將更改合并在一起。很多時候,這種合并的努力導致進一步的構建中斷等等。
大提交
較大的提交是有問題的,因為它們包含多個可能與其他變更相沖突的更改:
這些較大的更改集意味著在完成登記之前需要更多的文件合并,進一步延長提交所需的時間。
然而,北京軟件公司開發(fā)人員大量提交的原因有很多:耗時的測試,大功能,網(wǎng)絡延遲和緩慢的集成審批流程。因此,為了處理大的事情,必須考慮到這些根本原因。
合并沖突
合并沖突發(fā)生在不同開發(fā)者所做的更改沖突時。解決這樣的沖突可以付出巨大的努力:在成交的過程中這只是交付的問題,那么在選擇軟件開發(fā)公司中應避免那些誤區(qū)呢,可以看看這篇文章選擇app軟件開發(fā)公司時要避免的10個誤區(qū)
我們感覺到長時間運行的分支機構合并了太多次的痛苦。合并沖突可能需要幾個小時才能解決,而且很容易意外中斷代碼庫。
合并沖突可能由長時間運行的分支或大提交引起。延遲執(zhí)行過程,如冗長的代碼審查也可能導致合并沖突[C21]。在某些情況下,合并沖突可能更少:如果軟件開發(fā)人員在源代碼的不同部分工作,或者有少量軟件開發(fā)人員。