# 讓開發自動化: 部署自動化模式，第 1 部分 _用于實現簡便部署的模式_ Java? 部署常常很混亂，容易出現錯誤，需要許多手工操作，這會延誤向用戶交付軟件的時間。本文是分兩部分的 [_讓開發自動化_](http://www.ibm.com/developerworks/cn/java/j-ap/) 系列文章的第 1 部分。在本文中，自動化專家 Paul Duvall 將介紹用于開發可靠、可重復且一致的部署流程的一些關鍵模式，幫助讀者為 Java 應用程序生成簡便的部署。 軟件部署常常被視為不可避免的麻煩，可以在遇到它時應付一下，以后就不用理會了。但是，與開發周期的其他部分一樣，可以并且應該對部署應用軟件工程原理。在手工進行部署時，部署是一個重復且容易出現錯誤的流程。正如可以通過自動化構建來減少錯誤并加快軟件開發，也可以通過自動化部署流程來減少錯誤和加快軟件交付。 在前面的一期_讓開發自動化_ “[使用自動化加速部署](http://www.ibm.com/developerworks/cn/java/j-ap01088/)” 中，介紹了一種把軟件遠程部署到多個目標環境中的技術。本文在更高的層面上討論自動化部署。正如存在一些用于軟件開發的模式，也有一些用于部署的模式。在過去幾年里，我一直在收集和整理這些模式。在第 1 部分中，我將介紹 8 個部署模式并提供相關示例： * **Repository**，這個模式在一個集中的存儲庫中管理所有配置文件，這樣就可以使用 Scripted Deployment 生成有效的軟件 * **Scripted Deployment**，這個模式通過腳本執行所有部署操作，這樣在執行部署時就不需要人為干預 * **Single Command**，這個模式減少部署的復雜性，確保實現部署流程的無頭執行（Headless Execution） * **Tokenize Configuration**，這個模式提供一種可重復的把可變信息注入配置文件中的方法 * **Externalized Configuration**，這個模式可以_一次性地_ 輸入在目標環境之間有差異的信息 * **Template Verifier**，這個模式幫助確保所有目標環境屬性都是相同的 * **Headless Execution**，這個模式提供一種在自動化流程中安全地訪問多臺機器的方法 * **Unified Deployment**，這個模式幫助建立可以在許多目標環境中運行的單一部署腳本 第 2 部分將介紹更多的部署模式。 ## 關于本系列 作為開發人員，我們致力于為用戶自動化流程；但許多開發人員疏忽了自動化我們自己的開發流程的機會。為此，我們編寫了 [_讓開發自動化_](http://www.ibm.com/developerworks/cn/java/j-ap/) 系列文章，專門探討軟件開發流程自動化的實踐應用，為您介紹_何時_ 以及_如何_ 成功應用自動化。 圖 1 說明本文討論的部署模式之間的關系： ##### 圖 1\. 部署自動化模式  我將依次討論每個模式。在這個過程中，您會逐漸理解圖 1 中顯示的關系。 ## 把所有文件提交給一個版本控制存儲庫 **名稱**：Repository **模式**：所有文件都被提交給版本控制存儲庫 — 在部署上下文中，這是指所有_配置文件_ 和工具。 **反模式**：一些團隊把這些信息放在一個具有訪問控制的共享驅動器上。其他團隊可能僅僅把信息放在自己的機器上，然后把它們復制到目標環境中。 作為一般規則，我建議開發團隊簽入創建軟件所需的_所有_ 文件。有時候，這個規則有一些例外情況，但是不常見。在部署上下文中，一些團隊錯誤地認為服務器和服務器配置是固定不變的資產。盡管有時候簽入大的二進制代碼比較困難，但是應該把配置、數據庫腳本以及所有構建和部署腳本提交給版本控制存儲庫。使用 Repository 模式對于實現下面討論的 Scripted Deployment 和 Single Command 模式很有幫助。 * * * ## 用腳本執行所有部署流程 **名稱**：Scripted Deployment **模式**：在腳本中編寫所有部署流程。 **反模式**：一些團隊可能手工配置部署任務，比如安裝和配置 Web 容器。其他團隊可能使用容器提供的基于 GUI 的管理工具針對特定環境修改容器。盡管這種方式最初可以簡化配置的手工修改，但是如果要在許多目標環境中頻繁地執行部署，這就不合適了。另外，在_首次_ 使用時，基于 GUI 的管理工具對于部署非常有幫助。但是，因為許多人必須重復執行這些流程，所以這種方式的可伸縮性很差且容易出現錯誤。 清單 1 通過實現 Scripted Deployment 模式對啟動（或重新啟動）Tomcat Web 容器的流程進行自動化。這個流程是用 Apache Ant 構建腳本語言編寫的。 ##### 清單 1\. 啟動 Tomcat Web 容器的示例 ``` <available file="@{tomcat.home}/server/@{tomcat.server.name}/bin" property="tomcat.bin.exists"/> <if> <isset property="tomcat.bin.exists"/> <then> <echo message="Starting tomcat instance at @{tomcat.home} with start_tomcat" /> <exec executable="@{tomcat.home}/server/@{tomcat.server.name}/bin/start_tomcat" osfamily="unix" /> </then> <else> <echo message="Starting tomcat instance at @{tomcat.home} with startup.sh" /> <exec osfamily="unix" executable="chmod" spawn="true"> <arg value="+x" /> <arg file="@{tomcat.home}/bin/startup.sh" /> <arg file="@{tomcat.home}/bin/shutdown.sh" /> </exec> <exec executable="sh" osfamily="unix" dir="@{tomcat.home}/bin" spawn="true"> <env key="NOPAUSE" value="true" /> <arg line="startup.sh" /> </exec> <exec osfamily="windows" executable="cmd" dir="@{tomcat.home}/bin" spawn="true" > <env key="NOPAUSE" value="true" /> <arg line="/c startup.bat" /> </exec> <sleep seconds="15" /> </else> </if> ``` 通過腳本執行這個流程，就不再需要在 Tomcat 提供的 GUI 管理界面中執行操作。另外，因為這個流程已經腳本化了，可以在全面的自動化部署中通過無頭流程運行它。 * * * ## 通過單一命令運行部署 **名稱**：Single Command **模式**：部署者或無頭流程只需輸入_單一命令_，即可為用戶生成有效的軟件。 **反模式**：某些部署流程要求部署者輸入多個命令并完成多個流程，比如復制文件、修改配置文件、重新啟動服務器、設置密碼等等，這些重復的操作很容易出現錯誤。如果他們走運，手頭有詳細的文檔，能夠指導他們執行這些操作。但是無論如何，要求人員執行部署流程都會增加出錯的風險，導致時間瓶頸，延誤軟件在多個目標環境中的發布。 ## 開發環境不等于生產環境 即使軟件能夠在開發環境或 QA 環境中正常工作，也不意味著它會在生產環境中正常工作，因為環境之間可能存在各種差異。這就是為什么通過腳本執行所有部署工作是很重要的。 在編寫部署時，您的客戶常常是團隊、組織和公司中的其他人 — 甚至可能是計算機。運行部署的方法越復雜，別人或無頭流程成功執行它的可能性就越小。清單 2 給出一個簡單的單一命令部署示例： ##### 清單 2\. 使用 Ant 執行單一命令部署 ``` ant -Dproperties.file=$USERHOME/projects/petstore/properties/dev-install.properties \ deploy:remote:install ``` 清單 2 中的命令執行一個名為 `deploy:remote:install` 的 Ant 任務，并傳遞一個與環境相關的 .properties 文件，從而把軟件遠程部署到其他計算機上。這個任務執行的操作包括使用 Secure Copy protocol (SCP) 安全地復制文件；通過 Secure Shell (SSH) 在遠程計算機上安全地執行命令；安裝、配置和重新啟動 Web 容器；以及其他流程 — 這些都不需要人為干預。顯然，用戶可以輸入這個命令；但是因為它非常簡單，所以很容易通過無頭流程（比如持續集成或構建管理服務器）運行它。 * * * ## 把可變信息注入配置文件 **名稱**：Tokenize Configuration **模式**：把標記化的值輸入配置文件，然后在 Scripted Deployment 期間根據 Repository 中的 Externalized Configuration 屬性替換它們。 **反模式**：把與目標相關的數據輸入每個環境中的配置文件。 清單 3 中的 XML 文件用來管理 Web 容器和數據庫服務器之間的配置。在這個文件中，我使用 `@` 符號設置了一些標記。在自動化部署期間，一個腳本將把這些標記替換為來自 Externalized Configuration 文件的實際值。 ##### 清單 3\. 標記化的 Web 容器配置文件 ``` <datasources> <local-tx-datasource> <jndi-name>@application.context.name@</jndi-name> <use-java-context>false</use-java-context> <connection-url>@database.url@</connection-url> <user-name>@database.user@</user-name> <password>@database.password@</password> <driver-class>@database.driver@</driver-class> </local-tx-datasource> </datasources> ``` 把與環境相關的值標記化，就使 Scripted Deployment 能夠通過 Unified Deployment 支持多個環境。 * * * ## 提取所有與環境相關的屬性 **名稱**：Externalize Configuration **模式**：把所有可變值從應用程序配置轉移到構建時屬性中。 **反模式**：一些團隊為每個目標環境手工硬編碼這些值，或者使用 GUI 工具執行同樣的工作。 清單 4 給出一些常常包含在與應用程序相關的配置文件中的屬性。通過把所有_可變值_ 集中在一個 .properties 文件，就可以把數據（可變屬性）與行為（部署腳本）分隔開。換句話說，無論在哪個目標環境中，自動化部署流程都以相同的方式運行。 ##### 清單 4\. 可以提取到與應用程序相關的文件中的示例屬性 ``` authentication.type=db application.url=http://${tomcat.server.hostname}:${tomcat.server.port}/brewery-webapp database.type=mysql database.server=localhost database.port=3306 database.name=mydb database.user=myuser! database.password=mypa$$! database.url=jdbc:mysql://${database.server}:${database.port}/${database.name} tomcat.server.hostname=localhost tomcat.server.name=default tomcat.web.password=pa$$123! tomcat.cobraorb.port=12748 ``` 清單 4 中的值常常分散在源代碼、服務器配置、XML、.properties 和其他文件中。另外，我發現這些數據常常在系統中重復出現，這會導致難以調試的部署問題。通過把這些信息從許多地方集中到一個 .properties 文件中，可以減少發生部署問題的可能性。 * * * ## 通過無頭執行減少麻煩 **名稱**：Headless Execution **模式**：安全地與多臺計算機進行交互，而不需要輸入任何命令。 **反模式**：由人以不同的用戶身份手工登錄并訪問每臺計算機，然后執行復制文件、配置值等操作。 盡管 “無頭執行” 這個名稱有點兒夸張，但是在需要通過自動化流程遠程訪問其他計算機時，無頭執行確實是很有效的解決方案。通過使用公共密鑰基礎結構 (PKI)，可以把通常由開發人員、構建工程師、軟件配置管理 (SCM) 或操作員執行的命令組合為自動化的解決方案。在圖 2 中，在構建計算機和 SSH 上安裝一個私有密鑰文件。在每個與目標相關的 .properties 文件中定義具體值。這通常包括私有密鑰文件名和位置、SSH 端口號和主機名。目標計算機包含公共 SSH 密鑰文件，從而完成 SSH 握手。 ##### 圖 2\. 使用 SSH 密鑰實現 Headless Execution 模式  如果使用這種方式，Scripted Deployment 就可以從構建環境對目標環境執行部署流程，不需要人為干預。 * * * ## 檢查在不同的環境中屬性是否相同 **名稱**：Template Verifier **模式**：創建一個模板文件，所有目標環境屬性都基于這個文件。 **反模式**：一些團隊執行手工檢查、嘗試和糾錯（在部署失敗時，檢查失敗的原因），或者把文件 “隱藏” 在計算機上。 問題在于，需要確保在每個環境中具有完全相同的屬性。但是，在自動化環境中如何檢查這一點呢？根據一個模板 .properties 文件檢查所有目標環境文件，就可以確保所有屬性在任何目標環境中都是相同的。在圖 3 中，構建腳本運行一個 Ant 任務，此任務對 template.properties 和與目標相關的 .properties 文件（dev.properties、qa.properties 等）中的_屬性_（而不是值）進行比較。如果發現差異，部署就會失敗。 ##### 圖 3\. Template Verifier 模式的實現  清單 5 給出一個示例 template.properties 文件。注意，它只包含_屬性_，因為值與這個問題無關。 ##### 清單 5\. 包含屬性但不包含值的模板文件 ``` db.database= db.username= db.password= db.hostname= db.driver= db.port= db.url= ``` 清單 6 給出 dev.properties（或 qa.properties 等）文件的片段。注意，它既包含屬性，_也_ 包含值。這些值是與目標環境相關的。 ##### 清單 6\. 基于模板文件的目標環境屬性文件 ``` db.database=brewery db.username=root db.password=p@ssword db.hostname=dev1.domain.com db.driver=com.mysql.jdbc.Driver db.port=3306 db.url=jdbc:mysql://${db.hostname}:${db.port}/${db.database} ``` * * * ## 同時在多個目標環境中執行部署 **名稱**：Unified Deployment **模式**：創建能夠在不同的平臺和目標環境中運行的單一部署腳本。 **反模式**：一些團隊為每個目標環境（甚至特定的計算機）使用不同的部署腳本。 盡管一些部署流程只在某些環境中運行，但是所有流程應該_能夠_ 在_任何_ 目標環境中運行。例如，在開發、測試、準備和生產環境中應該運行相同的 Scripted Deployment，但是使用不同的 Externalized Configuration 文件。使用 Template Verifier 檢查 Externalized Configuration 屬性。 圖 4 給出一個能夠在多個目標環境中執行部署的部署腳本： ##### 圖 4\. 單一部署，多個目標環境  * * * ## 結束語 部署是軟件開發中另一個適合自動化的方面。自動化部署可以受益于可靠且可重復的流程：提高準確性、速度和控制能力。在本文中，我討論了 8 個適用于軟件部署自動化的模式。第 2 部分將討論更多的模式，包括 Remote Deployment、Disposable Containers、Deployment Test 和 Environment Rollback。