連續發布的並行開發

並行開發？

你的公司希望應用程式能夠定期推出一系列的主要功能。作為出色的極限開發者（XP），你們知道連續發布的並行開發是最好的選擇。然而，每個主要功能的工作量和所需時間都很大，需要不同的專案團隊合作完成這個計劃。其中一些團隊將在同一程式碼庫中工作，有些則可能是應用程式需要通過網路呼叫的依賴服務。看起來不是所有工作量都是等價的，但業務希望能夠進行具體的推出計劃，包括日期，並且能夠提前十八個月計劃。他們之所以具體到這個程度，是因為這對用戶群體（員工、客戶、顧客或公眾成員）產生影響。推動部門可能包括培訓、市場營銷與財務。

哎呀？

你們有可能會面臨由隨機壞消息事件引發的一些災難。這些事情在軟體開發中是有可能且確實會發生的。

或許某件事被低估了 50 ％，而這一點比預期的更晚才被察覺。假設公司沒有試圖通過增加人手來解決問題，所有接下來的版本釋出是否也應該延後？我們都知道 Fred Brook 的《人月神話》和 Edward Yourdon 的《死亡行軍》。

重新排序版本發布？

一個有說服力的解決方案是改變版本發布的順序。對於企業來說，即使這需要重新規劃，並且會在市場營銷或教育方面帶來一些問題，考慮到受影響的員工、客戶、顧客或外部成員，這仍然有可能是一種解法。

取消合併？

問題在於，開發團隊可能需要面對選擇性地取消合併或瘋狂註解程式，這取決於已經合併了哪些內容。不同的分支模型對合併的影響各不相同，無論這些合併行為是早還是晚。這本身就對業務造成干擾，因為他們擔心可能會目睹由於重新配置，和新的緊張情緒所導致的額外延遲。

功能標誌、抽象分支和流水線

如果你的團隊已經制定了主幹開發，功能標誌基於抽象的可插拔元件（與抽象分支概念雷同），這使其完美地處於重新排序發布的位置，並且只對開發團隊的吞吐量產生較小的影響。

案例研究

在 2012 年一個航空公司的實際案例研究中，當計劃發布進入開發的後期階段時，一個合作夥伴表示他們實際上無法在該日期前完成。他們的整合部分還沒有準備好。航空公司的程式碼已經完成，但現在必須重新安排發布順序。開發團隊的管理層擔心在整理混亂情況時可能會有一些停機時間。該團隊設法啟動一個新的持續整合（CI）流水線，並照調整切換功能標誌或開關以顯示功能的新排列。新的 CI 流水線證實了他們在命令列建置中已經看到的情況，即自動化測試中存在失敗（而且頁面中的某些內容看起來並不完全正確）。經過幾次快速修復後，開發團隊向航空公司的管理層保證，版本發布可以合理地以任何順序進行發布。

選擇主幹開發、功能標誌和抽象分支可以被說是對更大調度變更成本的避險策略。

其他參考資料

顯示參考資料