經過持續交付提升生產率

當今軟件開發領域的一個有趣特徵是，儘管有些人認爲「持續交付」已成定局，但仍有許多團隊沒有看到或正在努力實現收益。release少許功能的想法一般看起來像是一種簡單的解決方案，能夠減輕因大量風險性發布而帶來的痛苦，咱們以此方式解決了很是困難的障礙。

今最流行的軟件開發方法是Scrum。 Scrum提倡讓您的應用程序準備在每次（大約兩週長）衝刺結束時發佈。我不是在這裏挑刺Scrum團隊，可是將多個功能捆綁到發行版中而後再部署到生產環境中的任何方法都是有問題的。

• 他們將許多功能和修補程序捆綁在一塊兒。若是其中任何一個在測試中失敗，它將延遲整個捆綁包。若是其中任何一個生產中斷，則須要回滾所有功能。
• 僅僅由於還有更多的東西，它們增長了某些東西中斷，測試失敗等的風險。將大量release視爲大量小風險粘合在一塊兒，造成巨大的風險球，而後將其扔到生產環境中。
• 增長了工做量-彷佛已經完成（編碼）但實際上正在等待下一步（測試，生產部署）的工做，這可能會將其發送回pipeline中的上一個階段。

鑑於大量發佈會帶來風險而且容易出錯，爲何這麼多團隊仍然堅持使用它們呢？我發現有兩個重複的問題不利於採用「持續交付」：打破舊習慣和錯誤的指望。

CD如何打破舊習慣？

CD在發佈過程當中轉移了隱藏的瓶頸。對於開發人員而言，帶着一種祝福的心態移交給QA和運維，延遲了在真實環境中發生不可避免的混亂，感受上像在提升生產力。從團隊經理的角度來看，它看起來也頗有成效。在大多數sprint中，開發人員彷佛忙於編寫代碼。發佈日期臨近時會發生什麼？在進行全部測試並能夠關閉辦公室的燈以前，須要付出巨大的努力進行測試，發佈，修復構建並再次進行測試。

許多管理人員和開發人員都接受了看似高生產率和易於出錯的版本之間的這種迭代，這是軟件開發的事實。從這個角度來看，「持續交付」看起來是違反直覺的：若是發佈是壓力大，容易出錯的事件，爲何會有更多的發佈？

錯誤的指望

採用CD的第二個障礙是抱有錯誤的指望。咱們每一個人都在觀看討論並閱讀有關將CD部署到天天生產50倍的公司的博客。對不對？可是咱們並不以爲這對咱們很重要-咱們的客戶能夠每隔一段時間看到一個新版本就徹底能夠了（也許更加溫馨）。所以，CD並不適合咱們，它適合那些出於某種緣由始終必須交付新產品的其餘公司。

這些成功案例中一般會丟失的是，這與客戶無關。這是關於公司內部軟件開發的方式。關於小幅提升生產率和管理風險。即便許多敏捷團隊設法忽略它，這也是一個很是敏捷的想法。

限制正在進行工做的重要性

那麼，與發佈大版本相比，交付小版本如何提升生產率？關鍵是正在進行的工做。進行中的每一項工做都會減慢團隊的速度，而且某個功能只有在投入生產後才能準備就緒。應用程序或基礎架構中的任何更改都須要經歷幾個階段。最後一個階段是以某種形式將更改登錄到用戶計算機上。一旦應用程序實現了對用戶的用途，而且所作的任何更改都沒有使該項目失效，則能夠選中該項目，而且再也不構成任何風險。

非全部環境都容許將每一個功能始終獨立地推送給用戶。公共Web應用程序是最好的，而第三方交付的企業應用程序一般是最差的。若是您的環境不容許天天向最終用戶推銷，請嘗試使其儘量接近他們。抓住一些業務分析師並將其視爲真實用戶（遷移數據，僅經過官方渠道進行交流等）。

還沒有進入用戶手中的每一個功能都想像成準備就緒的炸彈。進行中的工做既分散精力又是風險。

讓咱們來講明一下進行中的工做會如何吸引您。您的CatsRUs™團隊正在忙於完成衝刺，而企業急於提供新的排名按鈕，該按鈕可以使用戶給貓照片1至5星。您有一個由8個開發人員，4個SET（測試中的軟件工程師）和2個SRE（站點可靠性工程師）組成的龐大團隊。

因爲sprint持續了兩個星期，所以您但願在發行版中得到儘量多的功能。 8個開發人員能夠輕鬆地開始處理6個不一樣問題的sprint，甚至可能在兩週內完成10個。其中之一將是銷售部門腦門熱的時候簽署合同所承諾的排名按鈕。

排名按鈕上的工做進展順利，三天後已經過質量檢查。團隊感到放心，將精力集中在完成其他功能上。用戶管理的改進將須要更改數據庫架構，可是應該能夠很好地進行處理。最終，在第二週結束時，全部功能要麼完成，要麼從衝刺中刪除。團隊已準備好將全部內容打包併發布。 SRE部署到登臺環境，並注意到該應用程序沒法正常運行-用戶沒法登陸。事實證實，另外一個功能是在發行前的最後一天完成的，還沒有經過新的用戶數據庫模式進行測試。

所以，該版本須要回滾以解決該問題。修復和迴歸測試將花費2天的時間來測試全部可能受影響的內容。管理層很緊張，團隊沒有休息，可是終於有一個新版本發佈併成功部署到生產中。一項不重要的更改意外地延遲了一項重要功能的交付。

生產中的某個功能出了問題，所以該版本會回滾。

解決上述問題的絕佳方法是持續交付。將該排名功能一直推到生產階段，而不會與其餘任何功能捆綁在一塊兒。它可能不如在晴天無事的狀況下建立大型發行版那樣有效，由於迴歸測試和部署須要作更屢次。可是，下降風險和增強控制能夠彌補這一不足。固然，若是您投入精力，迴歸測試和部署均可以愈來愈自動化。

在連續交付過程當中，存在問題的功能不會回滾其餘功能。

結論

在採用敏捷的工做方法以後，持續交付是您能夠對交付過程作出的最重要的改進。經過批處理較大版本的功能來進行工做將最終增長部署風險並下降團隊生產力。試用CD幾周，您會發現交付過程甚至變得更加簡單，由於許多項目管理都圍繞着跟蹤正在進行的工做項。

對於真正高效的CD過程，流水線各個階段的自動化相當重要。靈活的應用程序體系結構，例如圍繞獨立微服務組織的體系結構，還有助於安全地部署各個變動。這些問題不在本博客的討論範圍以內，可是一旦您採用持續交付，就須要注意在這些方面對團隊形成更大的壓力。