在前文《軟件自我識別》中，我們討論了如果使軟件做到自我識別，以促進自動化部署和版本檢測等工作。 隨著互聯網的飛速發展，以及基礎設施的改進，越來越多的業務被放在了“云”端。管理數千臺服務器和各種應用程序的不同版本已經是一種常規事務了。那么如果管理好這些機器和代碼嗎？本文將介紹一些最佳實踐，來幫助大家更好的完成相關的事務。

　　一、測試代碼不是二等公民

　　業務壓力讓團隊人力顯得有點兒緊張。一天下午，大家在緊張的工作著，新的版本即將發布了。突然，有兩個同事的對話引起了 Joe 的注意。

　　“Hi，Sam。過來看一下，我這里有個自動化測試失敗了。”剛剛加入團隊的測試人員 Jared 叫了 Sam 一聲。

　　“咦？我本地沒有這個測試，可我更新過我本地的代碼了呀？”Sam 一臉茫然地應到。

　　“哦，是嗎？不會吧。我也是剛剛從 SVN 上更新了代碼。”Jared 說道。

　　“Jared，你再更新一下，也許是你在我提交之前更新的呢。。。哦，還是一樣的結果。那到我的工作站上看一下吧。”

　　“噢，原來你把測試放在了這里。”Sam 恍然大悟的樣子，“我們兩個人使用的測試套件版本是不一樣的。根據用戶的反饋，我們重新修改了產品的一個小功能，所以，這部分功能的原有自動化驗收測試邏輯就不對了。”。SVN 代碼倉庫的目錄結構如圖 1 所示。

圖 1 產品代碼與測試代碼分離

　　這時，Joe 也湊了過來。“嗯。我們應該修改一下我們的代碼在 SVN 中的組織結構。把測試代碼和產品代碼放在同一個代碼庫中，做到產品代碼與測試代碼同源。”

　　Jared 問道：“為什么要這么做呢？我在上一家公司的時候，測試團隊也是把功能測試用例放在公司自行開發的一個測試用例管理平臺上進行管理。當需要做老版本的回歸測試（比如 V1.0）時，我們只要在這個平臺上勾選上該版本對應的測試用例，再點擊‘執行’按鈕，就可以了。當有新版本， 比如 V1.1 時，只要把 V1.0 的所有測試用例復制一份，標記為 V1.1，并在其上修改就可以了。測試代碼的組織方式常常是使用目錄結構來分離版本。”如圖 2 所示。

圖 2 以目錄方式對測試用例進行管理

　　Joe 回答到：“你剛才所說的做法，我也在其它公司見過。這種做法常見于使用傳統瀑布開發模式的團隊，即開發階段與測試階段分離。在開發階段，大家并不會頻繁運行相應的自動化測試，這些自動化測試是為測試人員服務。而在我們這里，自動化測試是為所有人服務的，開發人員隨時都會運行測試。其實，我們大部分的測試都已經與產品代碼放在了同一個代碼倉庫中了。只是這一部分是比較老的代碼，需求也一直沒有變化，自動化測試也一直運行成功，所以就沒什么動力去遷移這部分測試代碼。”

　　Joe 停頓了一下，喝了一口咖啡，接著說道：“當我們做到產品代碼和測試代碼同源時，我們只需要從一個 svn 代碼倉庫中簽出某個版本的源文件，就同時得到到產品代碼，以及與該版本相對應的測試代碼。所以，不會出現版本不一致，或者需要手工挑選測試用例的問題。現在服務器很多，應用程序使用灰度放量發布的方式，在生產環境中可能會有多個版本。假如正在運行的某個版本出現了問題，需要修復，那么，我們很容易就能拿到與其對應的所有代碼。因此，不能把測試代碼作為代碼中的二等公民，而是應該得到與產品代碼同樣的重視。我們代碼庫中的目錄結構是這樣的。”如圖 3 所示。

圖 3 測試代碼與產品代碼同源

　　二、配置信息也是代碼

　　Alex 此時也湊了過來，接道：“不只是對代碼需要一視同仁，配置信息也一樣要放到代碼倉庫中。這方面，我們也是有著痛苦經歷的。記得是幾個月前，那時候我們的產品還不大，為了快速調整，我們經常在生產環境中直接修改配置信息，如數據庫連接，功能開關項或者 IP 地址什么的。結果，每次準備上線前的測試時，都要到生產環境上去下載一份配置信息。有一次，生產環境上的一臺機器出了問題，結果那臺機器上的所有信息都丟了，害得我們到處找，花了很長時間才把那臺機器重新配置好。現在都放在代碼倉庫中，就可靠多了。”

　　“配置信息是指哪些呢？”Jared 問道。

　　Joe 回答道：“配置信息包括應用程序相關的配置，以及程序部署時的相關配置。應用程序相關的配置是指影響應用程序行為的配置項，比如某個功能的開關、數據庫連接、緩存的大小等等。程序部署時的相關配置是指部署在不同機器上的程序組件是如何相互連接的，如 IP 地址等等。”

　　“那有些配置信息是動態生成的，那怎么把它放到 SVN 中呢？”Jared 接著問道。

　　“我們首先要把動態信息與靜態信息分開。一般對于動態信息來說，只要把其變動的規則保存在 SVN 中就可以了。” Alex 答道。“比如，某些 IP 地址或內部域名是自動配置的，那么就把自動配置的腳本放到 SVN 中就行了。這樣，一旦出了問題，我們也可以確切地知道，所用的分配規則是什么樣的。”

　　“那生產環境的配置與測試環境的配置不同，與開發環境的配置也不同，怎么辦呢？”Jared 窮追不舍。

　　“這個好辦，只要存三份配置，對應三種不同的環境就可以了。”Joe 笑道，“所以，我們代碼目錄結構是這樣的。”他拿起筆，在紙上畫了一下，如圖 4 所示。

圖 4 以業務為核心組織產品結構

　　三、腳本文件也是源代碼

　　“嗨，Joe。這里的 script 目錄里面放什么的呢？” Jared 問道。

　　“哦，這個目錄是放所有我們用到的腳本的。” Alex 笑著說，“以前大家在測試、部署等工作中寫了很多腳本，用在各自的工作中。現在我們統一放在這個目錄中，這樣所有人都可以使用相同的腳本做相同的事情。比如，當開發人員在自己調試時，只要執行部署腳本 autodeploy，它就會從開發配置目錄 (conf/dev)中讀取相關配置，部署好開發調試環境。而測試人員使用同一個部署腳本 autodeploy，它就會從測試配置目錄（conf/test）目錄中讀取相關配置，部署好測試環境，生產環境部署也運行同一個腳本，只不過說生產環境配置而已。”

　　“這樣不錯。我們的腳本在最終向生產環境部署之前就已經被測試過很多次啦。” Jared 笑道。

　　四、數據也是代碼嗎？

　　“我們有點跑題了，回到我們最開始遇到的那個測試問題上吧。” Jared 說，“那個測試失敗，除了功能的小改動以外，log 里還有一些異常，好象是數據格式問題。”

　　“嗯，這部分測試用到的數據放在一個固定的共享目錄中了。可是，雖然文件名沒有變化，但其中的數據格式已經改了。也就是說，這份測試代碼與測試數據存在不一致性。” Joe 說道。

　　Alex 接道，“嗯，我們現在把數據也放到了代碼倉庫中。”

　　Jared 一臉狐疑，問道：“數據那么大，怎么放到代碼倉庫中呢？SVN 保存大數據并不高效，而且占用空間也比較大呀。”

　　“Alex 只說了完了一半。其實，我們是把大數據放在了一個我們自行開發的版本控制系統中了。當把一份大數據放在其上時，該系統會返回唯一的一個標識 ID，我們把它放在了這個產品代碼的 conf 目錄中。這樣，當簽出某個版本的代碼時，你就可以直接拿到對應的大數據了。如果大數據修改了，那只要把它再次放到那個大數據存儲系統中，然后把返回的唯一標識更新到對就應的 conf 目錄中就行了。”Joe 補充道。“如果沒有這樣一個大數據庫版本管理系統，也可以使用共享目錄，只不過，每個子目錄下保存一份數據，把這個子目錄地址放在 SVN 里，也就行了。”

　　“對于數據庫結構的修改，我們還有另外一種方法，就是利用類似于 DBmaintain 或是 DBDeploy 這樣的工具。把每一次數據庫結構的變更都寫到一個數據庫腳本，并把它們和代碼放到一起。這樣，升級過程就由這些工具就完成了。”

　　五、Everything is code

　　“哦，我明白了。”Jared 說道，“就是圍繞我們的服務或產品，將所有的東西進行版本管理。這樣，所有的內容都只有唯一的一個源，所有人都可以拿到同樣的信息，而且自動化工作也非常容易了。”

　　“是的。而且，當完成這一步以后，所有的事情自然都成為可跟蹤可追溯的了。”Joe 笑道：“這也算是一個額外的收益吧。”