持續集成之“Everything is code”

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

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

　　業務壓力讓團隊人力顯得有點兒緊張。一天下午，大家在緊張的工作著，新的版本即將發布了。突然，有兩個同事的對話引起了 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 代碼倉庫中簽出某個版本的源文件，就同時得到到產品代碼，以及與該版本相對應的測試代碼。所以，不會出現版本不一致，或者需要手工挑選測試用例的問題?，F在服務器很多，應用程序使用灰度放量發布的方式，在生產環境中可能會有多個版本。假如正在運行的某個版本出現了問題，需要修復，那么，我們很容易就能拿到與其對應的所有代碼。因此，不能把測試代碼作為代碼中的二等公民，而是應該得到與產品代碼同樣的重視。我們代碼庫中的目錄結構是這樣的。”如圖 3 所示。

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

　　二、配置信息也是代碼

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

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

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

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

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

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

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

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

　　三、腳本文件也是源代碼

原文轉自：http://kb.cnblogs.com/page/127846/