《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 組態管理。
沒有留言: