《Continuous Delivery 中文版》的主題是持續交付。這裡簡單整理一點跟 deployment 有關的東西。
Chapter 10：應用程式的部署與發佈
本章提到幾個值得了解的實務做法（雖然不見得有機會玩到）：
要在資料庫 schema 有變動的情況下做到 zero downtime deployment 真是件不容易的事！Chapter 12：資料管理
這一章有提到應用程式的資料庫版本管理／遷移（migration）。實務上，我覺得這個部分還挺麻煩的，想看看作者提供哪些良方。
目前我參與的專案是採用 Entity Framework Code First automatic migration。好處是，團隊成員能夠任意在自己的 feature branch 上面建立新的 migrations（也就是資料庫 schema 的異動）。至於缺點，在經過幾次產品的 release 之後就會發現，難免要解決 migration 失敗的問題。在嘗試解決這些疑難的過程中，我在一篇很實用的 MSDN 文章裡面看到一句話：
The bottom line is that automatic migrations initially look good in team environments, but in reality they just don't work.我覺得該文作者很誠實，而且必定也痛過，才斬釘截鐵寫出這麼一句話來。
本章提到一種方法：將應用程式部署與資料庫遷移解耦合。換句話說，就是讓 code 和 database 分開 deploy。此作法的一個要點是：
- 先部署應用程式的過渡版本，讓它可以跟目前版本的資料庫一起運作。接著，當確信新版本的應用程式非常穩定且不必還原，就可以將資料庫升級到新的版本。當然，這麼做之前，要對其進行備份。之後，當應用程式的下一個版本準備好部署時，就可以直接部署，而不必遷移資料庫了。
此時我隱約有一種感覺：要做到 zero-downtime deployment，除了採用藍綠部署或金絲雀部署，可能還得搭配上述方法。這篇文章說得更清楚些：Zero downtime during deployment using modified blue-green deployment strategy。
Chapter 14：版本控制進階
這一章的內容，我覺得如果先看過 Git Flow 文章，或者有實踐過 Git Flow，會更有感覺（比較不會像在看天書）。
Release Branch: 為每一次產品的 release 建立專屬的分支
「為了產品的 release 而建立分支」取代了「凍結程式碼」此種邪惡的做法，亦即幾天內不許將程式碼簽入版本控制，有時甚至是幾個星期。
除了 product release，還有一種發行叫做 maintenance release，是為了修正 production 環境上的重要問題，因此必須在下一次產品發布之前儘快解決。
Feature Branch: 為每一個 feature 建立分支
此作法可確保主線的穩定（維持在可建置、可發布的狀態）。
在目前的專案中，Feature 和 Release 分支都是開發團隊採用的作法。
在目前的專案中，Feature 和 Release 分支都是開發團隊採用的作法。
Team Branch: 為每一個團隊建立分支
沒用過這種作法，所以沒有評論。
我覺得翻譯得不好的地方
有些是個人的喜好，有些看起來是明顯的錯誤：
- 售票地獄：原文 ticket hell。建議：工單地獄。
- 業務團隊：原文 operation team。建議：維運團隊。
- 設置管理：原文 configuration management。建議：配置管理 or 組態管理。
沒有留言: