DevOps基礎-5.1-持續傳遞：小+快 = 更好

       這篇開始進入第五章的學習，第五章主要講的就是Continuous Delivery，簡稱CD，翻譯就是持續傳遞。在DevOps中CI和CD是兩個經常被提起的話題，在你以後工作中，經常要遇到這兩個單詞。第五章，你就明白什麼是CI 什麼是CD。

       你無法繞過DevOps，如果沒有關于持續內建和持續傳遞的大量讨論。在這一篇文章，我們将介紹五大優勢。在舊的傳遞軟體方式中，在開發過程中花費的大部分時間内，應用程式無需運作，至少不是整體運作。您隻需建構和部署應用程式，并在最後将其送出到測試階段。在項目後期大批量擷取錯誤報告。但是，在持續傳遞中，你有一個應用程式，可以自動建構每個代碼送出（PS，類似Jenkins的工具）。

       每次持續傳遞，運作單元測試，并将應用程式部署到類似生産的環境中。此外，還會運作自動驗收測試，并且在更改後，要麼通過測試或者失敗，當代碼check in進來後，隻需要幾分鐘時間就可以完成單元測試。現在有些定義是這樣描述：持續內建是經常自動建構和單元測試整個應用程式的實踐過程。理想情況下，在每個源代碼上check in，持續傳遞是将每個更改部署到類似環境的生産，并執行自動內建和驗收測試的附加實踐。

        持續部署将此擴充到每個變更都經過充分自動化測試的地方。它被自動部署到生産環境中。 Facebook，Etsy和Wealthfront等大型網絡都在使用持續部署。使用這些技術的最令人信服的原因之一是将産品推向市場所需的時間大大減少。2016年DevOps狀态報告發現，與同行相比，高性能IT組織可以按需部署，需要數天，數周或數月。

        高績效的IT組織能夠快速從概念轉向現金。允許快速實驗和市場驗證。我們現在看到組織每天部署一個給定的應用程式十次，甚至幾百次。您可能會認為快速周期和高頻率的變化會讓您看到品質下降，但實際情況恰恰相反。 是的，DevOps狀态報告還發現，這些高績效組織的變更失敗率比同行低三倍。

        這種品質的提高發生了，因為我們不是在開發生命周期結束時進行檢查，而是在傳遞管道中更早地內建測試。我們逐個評估和部署更改，而不是由數百個更改組成的大型實體。測試每次送出，并確定軟體處于運作狀态。你知道，Lean（一個精益模型）告訴我們，正在進行的高水準工作，換句話說，一次全部部署到生産環境的大數量任務，确實非常危險。持續內建的一個備受争議但重要的原則是，開發人員必須在Master或Trunk之外工作。（PS代碼分支的概念，可以了解一下）

        DevOps狀态調查的一個有趣發現是，在合并到Trunk之前，擁有非常短的生命周期（不到一天）的分支或分叉，總共少于三個活動分支，都有助于提高性能。 是的，簡而言之，我們縮減了與正在進行的工作相當的軟體內建更改量。對我來說，當我閱讀Jez Humble關于持續傳遞的書時，所有這些都真的被點選了。它提出了一個批量大小。從這本書中思考的一句話是“這不是你能提​​供多少，而是多少。” DevOps狀态報告還說，高績效IT組織提到，将更改部署到生産中所需的準備時間不到一小時。

        低績效者需要一到六個月的交貨時間。我的意思是這是一個巨大的，巨大的競争優勢。你能從多久從失敗狀态中恢複？關于在持續傳遞環境中工作的有趣部分是有兩個向量，使您的平均恢複時間更短。首先，一旦你處于失敗狀态并且你已經提出了補救措施，它就可以像任何其他變化一樣對待并快速推出，而不會破壞你的正常過程。第二個也是不太明顯的好處是使用持續傳遞來找出失敗的原因。例如，在我的工作中，我們在幾天的時間内資料庫連接配接增長緩慢。它一直在增長，直到我們達到極限，一切都破裂了。通過将連接配接增長圖與同一時間視窗中發生的部署重疊，我可以快速确定哪個送出引入了錯誤。在我之前的工作中，同樣的練習花費了數周時間，因為這一變化發生在季度釋出中，同時發生了數百次變更。對我而言，這證明持續傳遞實際上減少了MTTR，并且具有巨大的運維影響。在接下來的部分中，我們将讨論持續內建，以及每個應該存在的持續傳遞管道（Pipeline）和實踐。

      這篇的，大概了解了一下什麼是持續傳遞和持續內建的概念。持續傳遞就是這麼具體例子去了解。加入要給銀行外包一個軟體項目給一個外包公司。傳統軟體傳遞是，半年或者一年之後傳遞。如果使用DevOps的文化，進行持續傳遞，半個月傳遞給銀行一次甚至一個禮拜一次。這樣半年或者一年中需要做幾百次的持續傳遞。持續傳遞離不開持續內建，下一篇介紹持續內建。是以，我們鼓勵，代碼變更小的運維部署加上快速的部署時間，這種的方式是最優的軟體傳遞方法。