[讀書筆記] Deploying and Releasing Applications

Deploying and Releasing Applications

1.         Creating a Release Strategy

          i.              The Release Plan

(1) 首次部署的步驟

(2) 預計怎麼進行Smoke Test

(3) 如果部署失敗，如何取消

(4) 如何備份與還原

(5) Log

(6) 如何監控

(7) 資料如何轉移

(8) 前一次部署失敗的紀錄及後續Solution

         ii.              Releasing Products

2.         Deploying and Promoting Your Application

          i.              The First Deployment

首次部署會發生在首次Iteration結束時，你應具備以下內容：

                (1) Deployment pipeline’s commit stage

        (2) A production-like environment

        (3) An automated process

        (4) A simple smoke test

A production-like environment：

(1) The same OS

(2) The same software (none of the development toolchain)

        (3) Be managed the same way as the production environment (Chapter11)

        (4) The UAT environment should be representative of your clients’ hardware statistics

         ii.              Modeling Your Release Process and Promoting Builds

                

建置必須得通過那些階段？

每個階段的驗收標準？

每個驗收標準由誰批准？

再次強調 自動化部屬機制 使Upgrade變得容易

       iii.              Promoting Configuration

需要upgrade的不只是Binary Files

還包括了環境及應用程式的設置

利用smoke test 驗證設置資訊是否正確

       iv.              Orchestration

Orchestration => 管絃樂的編制。

因為應用程式可能會共用同一個環境，所以要確保不會影響其他程式

         v.              Deployments to Staging Environments

在你將程式交出去之前，應該要在試運行環境執行最後的測試。

在專案開始前就必須規劃以下事項：

(1) 確保所有環境OK

(2) 自動化流程

(3) Smoke Test

(4) 測量應用程式的warm-up期

(5) 與外部系統進行整合測試

(6) Blue-Green Deployment

(7) Canary Release

(8) 將通過測試的變更版本部署至試運行環境

3.         Rolling Back Deployments and Zero-Downtime Releases

還原時注意兩個原則：

(1) 備份

(2) 練習還原計劃

          i.              Rolling Back by Redeploying the Previous Good Version

最簡單

重新部署前一個沒有問題的版本

缺點：

難以除錯

新資料可能遺失

         ii.              Zero-Downtime Releases

將User從一個版本幾乎瞬間轉移到另一個版本，後面會介紹兩種強大的方法。Blue-Green Deployments AND Canary Releasing

       iii.              Blue-Green Deployments

                

兩個相同的生產環境：藍環境、綠環境。

假如User目前在綠環境，如果要發佈新版本，會先發佈至藍環境，等一切就緒之後，再將User切到藍環境。

問題：

小心管理DB

Solution：

暫時唯獨

Chapter12

如果只有一個生產環境，也可以使用Blue-Green Deployment。

ð 讓應用程式的副本存取自己的資源

變體：shadow environment releasing (影子環境發佈)

試運行環境與生產環境彼此切換

       iv.              Canary Releasing

                 

金絲雀發佈就是把應用程式的某個新版本部署到生產環境的部分伺服器中。進而快速取得回饋。

好處：

(1) 容易還原

   => 將User 引導回沒問題的版本

(2) 能做A/B Testing

   => 小樣本測試新功能

(3) 方便做容量測試

   => 透過逐漸增加負載的方式做容量測試

問題：

如果是需要User自行安裝在自己環境的軟體不適用

Solution：

讓軟體能夠自動地從伺服器中取得新版本並自動升級

限制：

共用資源，所以要考慮

    (1) 資源於不同版本間的相容性

    (2) 非共用架構

生產環境中盡量保留兩個版本以內

4.         Emergency Fixes

任何情況下，緊急修復都不能破壞流程。緊急修復版本也要使用相同的建置、部署、測試與發佈流程。

有時候還原比部署新的修復更划算

5.         Continuous Deployment

再次強調 自動化 (包含部署到生產環境)

Continuous Deployment能與Canary Releasing結合使用，透過自動化流程將新版本發佈給一小群User，一旦確認新版本沒有問題，才發佈給全部的User。如此能降低持續部署的風險。

如果是User需要自行安裝的軟體，需要考慮下面4點：

        (1) Managing the upgrade experience

        (2) Migrating binaries, data, and configuration

        (3) Testing the upgrade process

(4) Getting crash reports from users

如果Upgrade很不穩定，那User選擇不要Upgrade很正確。

如果Upgrade很穩定，那沒必要給User選擇。

作者認為正確的作法是：

當Upgrade失敗時，程式必須能自動地還原至上一版並將失敗報告提供給Team。當Team修復這個問題，再次發動部署。這些應該悄悄發生，User不需要知道。

6.         Tips and Tricks

          i.              The People Who Do the Deployment Should Be Involved in Creating the Deployment Process

再次強調，真正要執行部署的人從流程開始時就應該開始參與。

         ii.              Log Deployment Activities

       iii.              Don’t Delete the Old Files, Move Them

不要刪除舊的檔案，要移動到別的位置

不要讓舊的檔案留在原處

       iv.              Deployment Is the Whole Team’s Responsibility

不要有所謂的部署專家，整個Team都該參與部署

         v.              Server Applications Should Not Have GUIs

自動化，不要有GUI

       vi.              Have a Warm-Up Period for a New Deployment

要有足夠的時間預熱

      vii.              Fail Fast

部署Script應該納入測試當中

不需要全面性的Unit Test，只需Smoke Test

    viii.              Don’t Make Changes Directly on the Production Environment

切記，不要直接修改生產環境，完全按照流程走

7.         Summary

• 一切要自動化
• 越頻繁地發佈，風險越小
• Blue-Green Deployments 以及Canary Releasing
• Team Member一起參與