
416
| 第十四章
以上只列舉一些可在外界看到的持續交付反模式。但還有一種最常見的問題值得在本章
單獨討論:“醜陋的”架構。
醜陋的架構:修改,還是不修改
在實作持續交付的某個時候,app 的架構可能會成為一種限制因素。本節將解釋幾個典
型的例子,與可行的解決方案。
進行架構復審
如果你正開始製作一個系統,或不確定當前的架構處於什麼狀態,那麼進行
正式的架構審查是很有價值的。這個程序不是只在白板上簡單地繪製(理
想化的)架構,Susan Fowler 的
Production-Ready Microservices
(O
’
Reilly)
及 Simon Brown 的
Software Architecture for Developers
(
https://leanpub.com/
software-architecture-for-developers
)( Leanpub)裡面有完成這項工作的實用方
法與技術。
每位最終用戶 / 顧客都有單獨的基礎程式及資料庫
你可能想要幫每一個用戶分出一個 app 基礎程式,尤其是當 app 共用一個類似的核心,
但每位顧客都希望客製化時。當企業只有兩三個顧客時,你或許可以這樣擴展,但這些
程式很快就會變得難以管理,因為你必須為所有系統加上必須的安全防護或 bug 的補
丁,而且因為各個基礎程式都分別演變,各處的修改都有可能稍有不同。
通常採取這種 app 風格的組織在進行持續交付時,必須建立與顧客數量相同的組建管
道,但情況也有可能變得無法管理,特別是在公司擁有多個產品的情況下。為了解決這 ...