持續交付的第一關鍵點：配置管理

今天我們來看持續交付的第一個關鍵點：配置管理。按照持續交付的理念，這裡所說的配置管理範圍會更廣，主要有以下幾個部分。

• 版本控制
• 依賴配置
• 軟體配置
• 環境配置

講持續交付，一上來就先講配置管理，主要還是想強調：配置管理是基礎，是關鍵。我們後面將要講的每一個持續交付環節，都對配置管理有很強的依賴。這個基礎工作做不好，也就談不上的持續交付的成功。勿在浮沙築高臺，我們做工具平臺或系統，一定要重視基礎的建設。

同時，這裡還有一個前提，就是一定要做到程式碼和配置的分離。不要讓配置寫死在程式碼裡，需要依靠嚴格的規範和約束。同時，對於那些因歷史原因遺留在程式碼中的配置，要多花些時間和精力把配置剝離出來，做這項工作沒有什麼好的方法或經驗，只能多上心，多投入些精力。

配置管理中，對於版本控制和依賴配置目前都有比較成熟的工具體系支援，也有豐富的實踐經驗供我們參考學習，下面我會做一個簡要的介紹。

對於軟體配置和環境配置管理，這兩項配置跟我們自身的業務軟體特性強相關，是整個持續交付過程的關鍵，我會結合我們自身的實踐經驗進行重點介紹和分享。

版本控制

版本控制的主要作用是保證團隊在交付軟體的過程中能夠高效協作，版本控制提供了一種保障機制。具體來說，就是團隊在協作開發程式碼的情況下，記錄下程式碼的每一次變更情況。

說到這裡，你是不是想到了SVN和Git這樣的版本管理工具？對，其實我們每天都在接觸，每天都在不停地做這個事情，所以目前看來這是一件很平常的事情。

關於這一部分我在後面的文章裡會介紹關於提交階段的實踐經驗。這裡我們只要知道，版本控制及其工具是必不可少的，因為這是開發團隊協作最基礎的工具。現在應該很少有團隊不採用版本控制的管理機制吧？

依賴管理

這裡以Java為例，我們使用Java進行開發，必然會依賴各種第三方的開源軟體包。同時，內部還會有不同元件的二方包。這些三方包和二方包就是一個應用編譯和執行時所依賴的部分。

有過開發經驗的同學肯定都知道，即使執行一個非常簡單的Web應用，都會有大量的jar包依賴。如果人工去管理這些依賴，基本上是不可能的，所以就需要有依賴管理的工具。

對於Java來說，我們熟知的依賴管理工具有Ant、Maven和Gradle。當然這些工具不僅僅提供依賴管理這樣單一的能力，一般都具備以下幾個能力：

• 二方包、三方包的倉庫（Repository）管理；
• 依賴管理；
• 構建打包。

下面介紹下我自己的實踐經驗。因為我們的經驗基礎都在Maven上，再加上Maven周邊有一些優秀外掛和業界經驗可以借鑑，比如後面將要介紹到的AutoConfg，所以我們選取了Maven作為主力構建工具。

大致用法是建立一個本地Maven源，構建時會優先從本地源中獲取依賴包，本地源中沒有對應的依賴時，會從公網上下載，同時快取到本地。這也是業界絕大多數公司採用的一種通用方案。具體如何構建打包呢？這個內容會在構建階段進行分享。

軟體配置

這裡我把軟體配置細化為兩類：一類是程式碼配置，一類是應用配置。

程式碼配置

我們可以這樣理解，程式碼配置是跟程式碼執行時的業務邏輯相關的。比如應用的服務介面、併發執行緒數、超時時間等這些執行時引數；還有類似於業務或技術上的開關，比如商品評論是否開放、優惠時間段設定等等。

應用配置

還記得我們在標準化文章中提到的應用嗎？應用配置就是應用這個物件的屬性和關係資訊。我們把應用配置放到持續交付這個場景中進行分析，對於這個配置可以細分為：

• 應用構建時配置，比如它的程式語言、Git地址以及構建方式等；
• 應用的部署配置，原始碼目錄、應用日誌目錄、Web日誌目錄、臨時目錄、指令碼目錄等；
• 應用的執行配置，應用啟停、服務上下線方式、健康監測方式等；
• 應用執行時與基礎元件的關聯關係，比如其依賴的DB、快取、訊息以及儲存的IP地址、域名、埠、使用者名稱或Token等。

從上面這種分類方式中，應該可以體會到，我們對於配置的分類，也是基於應用生命週期的不同階段進行分解和分析的。所以，標準化的過程也是一個持續迭代的過程。不同的場景下，一個應用可能會具備不同的屬性。這個時候，如果我們無法在一開始就把這些屬性梳理得清清楚楚，具備標準化的意識和思路就顯得更為重要。這樣，當我們遇到新場景的時候，隨時可以對它做標準化分析和建模。

程式碼配置和應用配置的區別

從上面的分析中，你有沒有找出兩者的區別？這裡建議你暫停一下，花一分鐘時間自己先想想程式碼配置和應用配置有什麼區別，再往下看。

從區別上講，我們可以認為程式碼配置是跟業務或程式碼邏輯相關的，動一下就會改變系統執行狀態，是執行時的配置，但不依賴周邊環境。而應用配置，是跟業務和程式碼邏輯無關的，不管你怎麼動，業務邏輯是不會改變的，但是它跟環境相關。

與環境相關，按階段分又大致可以分為兩個階段、三種情況。

• 第一種，軟體在交付過程中，環境會不一樣。比如我們正式釋出軟體前，會歷經開發測試環境、預發環境和生產環境等等。那開發測試環境訪問的DB，跟線上訪問的DB就不能是同一套。同時這個環境中的應用，依賴的大多是本環境內的基礎元件和應用，但不是必然，原因我們後面會講到。還有日誌級別也可能不同，比如測試環境可以開Debug級別，但是線上是絕對不允許開Debug的。
• 第二種，軟體交付上線後，線上可能會存在多機房環境，特別是有海外業務的公司，一個站點可能會在中國、北美、歐洲以及東南亞等不同區域建立當地訪問的分站點；或者大型網站做了單元化，在國內也會分多機房部署，這個時候每個機房的環境配置必然不同。
• 第三種，軟體交付後，一套軟體可能交付給不同的客戶，分別獨立執行，比如類似ERP、CRM這樣的軟體，或者私有部署的SaaS服務等。不同客戶的基礎環境是不一樣的，有的可能是Linux，有的是Unix，還有的可能是Windows，這時應用配置中的各種目錄、使用者名稱等資訊可能也是不一樣的，軟體的交付模式就取決於最終的客戶環境。

對於平臺類的產品，遇到第一、二種情況的可能性更大，這兩種情況更多的是對周邊依賴的配置不同，比如不同的服務註冊中心、DB、快取或訊息等等。對於一些針對不同客戶進行私有部署的產品，可能更多的是第三種情況，這種情況就是應用的基礎配置比如目錄、使用者名稱以及基礎軟體版本等會有不同。

我們回到程式碼配置和應用配置之間的區別這個問題上來。

對於程式碼配置，我們一般會通過Confg Server這樣專門的配置管理服務進行動態管理，在軟體執行過程中可以對其進行動態調整。之所以增加這些配置，主要是讓開發能夠以更靈活的方式處理業務邏輯。當然，也有一些為了穩定性保障而增加的配置，比如限流降級、預案開關等等。對於前者運維不必關注太多，而後者是運維關注的重點，這個內容我們後面講到穩定性部分會重點分享。

環境配置

對於應用配置，是我們在構建軟體包時就需要面對的問題。這個配置取決於環境，所以就延伸出持續交付過程中非常重要的一個配置管理：環境配置管理。解釋一下就是，不同環境中的應用配置管理。

環境配置是我們在持續交付過程中要關注的重中之重，也是最為複雜的一部分。我們自己的團隊在做多環境釋出和管理的時候，遇到最頭疼的問題就是環境配置管理，我們下一期就著重來聊聊環境的配置管理。

今天我和你分享了做持續交付的第一步：配置管理，主要包括版本控制、依賴配置、軟體配置和環境配置四個部分。關於今天分享的內容，你有怎樣的思考或疑問，歡迎你留言與我討論。

精選提問

1. 看到這裡下一步要乾的事情就是把程式碼配置和環境配置分離，以前程式碼配置和環境配置都下放給開發了，現在看來把環境配置分給運維控制更合適，比如docker啟動時的引數設定，尤其是jvm。

   反過來會不會更好，開發要能夠自助維護，儘量不依賴運維的人，運維可以制定標準和規範
   

2. 程式碼配置和環境配置混到一起確實存在問題，不同機房的同一個應用配置都不同，而且對於註冊中心，資料庫，快取的依賴都直接作為程式碼配置，所以當修改應用的一個引數，需要修改好多次。

   還是要區分開，因為管理方式會有不同