按照發布流程正確的部署軟件——二進製代碼和與之相關的配置文件——到你的開發、測試、驗收或產品環境(DTAP)是一項複雜的任務，涉及到眾多部門和團隊。不幸的是，在許多組織中這項關鍵的流程還是費時並容易出錯的。這篇文章裡，我們會探討開發團隊、運維團隊和其它相關方如何通過協作來準備一個“好”的部署軟件包。“好”的軟件包能減少部署中出錯的可能，並在需要自定義環境時提高部署的透明性。此外，我們還會檢視為何一個結構良好的部署包更易於轉為自動化部署，提升生產率和可靠性，同時減少軟件開發和維護生命周期中的錯誤和等待時間。區分部署過程中的擔憂:為什麽vs.如何做顯而易見，部署包需要包含應用程序的所有組件。而不僅僅是你自己的二進製包——EARs，WARs之類——通常這些包由集成構建產生，還應包含靜態內容、配置文件、共享庫、防火牆配置等等。特別還應包括應用服務器的參數和設置，比如消息隊列、連接工廠、數據源或類環境變量。實際上，軟件包應包含軟件生命周期中的所有內容，也就是那些需要一起被部署、升級和取消部署的內容。確保軟件包是“完備的可部署單元”對於一次可靠的部署來說是至關重要的，特別是在大規模環境中。指望目標中間件棧(middlewarestack)已經用“正確值”設置好是導致部署失敗的一個常見原因，這通常導致耗費很多時間來找出不同環境中的細微差異，這往往是令人沮喪的過程。部署包中隻包含配置信息，比如共享“服務”，例如為多個應用所共享的消息隊列或數據源，這種情形不鮮見。這些配置顯然應該按照有版本管理的、可部署的對象來處理，意味著這些配置文件按照和“普通”應用程序一樣嚴格的流程來發布。實際上，平穩、可靠的部署共享服務通常更為關鍵。除了確保軟件包最完整的描述了包含什麽使特定版本的應用程序或配置正確工作，軟件包還需要指出它們能夠運行所需的其它東西。換句話說，部署軟件包需要明確界定他們的先決條件和依賴，以便在匹配的環境上部署。準確的說，哪個部門負責部署和組織結構有很大關系。多數情況下是開發團隊，他們通常能使用持續構建工具使某些發布流程變為自動化，但發布過程還可能涉及其它團隊。舉例來說，讓DBA在發布前確認SQL腳本，或要中間件競爭中心(CenterofCompetence)檢查中間件配置的情況並不少見。請不要增量式發布(DeltaRelease)通常，開發的一個目標就是盡量減小對目標環境的影響。顯然，如果你的應用需要“不間斷運行”或多個應用程序共享一個集群，不必要的重啟服務器是要盡量避免的。為了達到這個目標，一個通常的做法是要求開發團隊提交一個“增量”發布包，其中值包含新的或修改過的系統模塊，並且隻部署這些模塊。經驗顯示，其實這是一個冒險的策略，應盡量避免，原因如下:
準備一個增量發布通常都是手工任務，完全依賴開發人員判斷哪些是修改過的模塊而哪些不是。這是一個耗時的又容易犯錯的過程，因而這個過程幾乎不可重複。
某個應用程序部署包的版本不適合實際部署——在最壞的情況下;可能所有的組件都需要上一版本。部署到一個“乾淨”的環境(設想需要快速設置幾個乾淨的鏡像來重現一個壓力問題)則更加複雜，

失敗的風險也因所有早期版本的包必須還要保留、並按照順序保留而增大。這是因為，當然，簡單來說就是數據庫增量備份的問題。
除非應用程序的每個版本都部署到了每個環境，否則在升級到相同版本時會產生問題，因為需要從不同的版本升級。這很快會在選擇了錯誤的增量發布包時導致混亂和產生錯誤。
不包括完整的包，而只是一些碎片的發布倉庫不是一個好的最終軟件庫的候選。
上述各點都無法讓減小部署影響的目標失效，這是顯而易見的。但部署包不能解決問題。實際上，部署流程才能應該通過在部署時推知哪些組件應增加、哪些被修改和哪些應移除，並據此實施來滿足這個需求。在時限壓力下手工實現上述部署流程是非常困難的(開發人員總是首先要做增量發布包)，而一個好的自動部署系統能夠很容易地實現上述目標。實際上，這是引入自動化部署的一個主要好處。在上述情況下，通常會設立專門的發布管理小組負責協調各種交付物，部署包按照便於恰當的人更新、修改和批準部署包的內容來組織是非常重要的。構建部署包是一個需要多個步驟的工作流，需要很多部門參與並耗時很長，也會產生準備“不完整”部署包的情況。這種情況下，發布管理系統不產生這種“不完整(draft)”發布包非常重要。我們建議由恰當的人員對已批準和已發布的包進行數字化簽名，這樣所有的包在部署前都通過驗證，為部署安全提供更進一步保障。深入到比特和字節選擇部署包格式主要是從方便起見。當然，部署包應該:
便於移動——最好是個單一文件
便於檢查
可壓縮，因為文本文件，如SQL或配置文件壓縮率很高
支持某種錯誤修正
可移植(比如開發人員在Windows環境開發，生產環境是UNIX)
可進行數字化簽名，目的是可以驗證待部署的包是通過審批的包。
所以通常來說，選擇一種壓縮文件格式，比如ZIP、TGZ或RPM，作為發布包的格式，但具體選擇哪種完全取決於你自己。
目前關於build文件格式沒有多少可說，因為除了WAR就是WAR。然而對於配置文件，情況則大不相同。目前，如果消息隊列和數據源的定義，甚至包本身(在發給運維團隊的成員的電子郵件中碰見這種情況很常見)通常都只是由人們可讀的文檔來描述的，比如發布注記(releasenotes)或按模板寫的Word文檔，這些文檔非常容易引起歧義並難於檢查修改。基於上述原因，配置文件也應該由機器可識別的格式來定義，比如XML。不幸的是，在這個方面目前還沒有什麽標準可推薦。事實上，這方面也是我們非常希望和用戶及供應商合作的。最好避免使用某種特定中間件定義的格式，比如WebSphere的XML配置。有時直接從已有的配置文件中抽取配置項看上去很方便，但這樣會限定於某個中間件供應商，在部署到不同的服務器環境時可能會遇到困難。通常，這是完全可以避免的，因為應用程序通常不會用到特定中間件的某個特定特性，因此可以在自己的配置文件中很容易的定義更“一般”的JMS隊列，數據源等等。最後，聲明文件或清單應該能描述包的內容。應該在這裡列出包的依賴關系，給操作者的描述和任何其它不容易找到的信息，比如開發人員的聯系信息，項目名稱，等等。聲明文件還需指出包內項目內容的類型，這些內容往往不容易通過名字判斷出來:EAR文件顯然是EAR但是一個ZIP文件可能包含HTTP服務器的的靜態內容、應用程序配置文件等等。再次指出，文件格式應該是機器可讀並可驗證的，同時也應該是容易自動生成的(比如從構建系統生成)。我們現在有了方便的、可移植的並能自動部署的軟件包，這個軟件包也是待部署應用程序要包含什麽內容的完整描述。到現在，我們還沒說任何如何部署的內容。發布注記在哪兒?部署和回滾計劃呢?理想情況下，應該沒有這些東西。更準確的說，標準的JavaEE應用程序的部署流程應該，以部署包內容為基礎，是足以完成正確部署的。應用程序特定的部署步驟意味著滿足該應用程序的些特殊要求，這些特殊要求在之前只有開發人員了解。當凌晨2點鍾時需要進行一次緊急部署，而無法聯系上開發人員，運維人員犯錯幾乎是不可避免的。簡單來說，開發人員應該知道什麽應該被部署，他們不應該為如何部署而操心。當然，組織內有標準的JavaEE部署流程是實現上述目標的先決條件，當你的組織有幾類不同的應用時可能有幾個流程。這個流程要足夠複雜，以便能覆蓋在部署時所需的各個組件和配置，但限制可選項的數量以保證流程的可維護性、測試性和可靠性也同樣重要。這必然會給開發技術加上一些限制條件。然而，相比在當前的情況下維護成本是運行應用程序中最大的日常開支這一事實，減小犯錯可能性、更可靠的部署流程帶來的好處勝過最大化開發靈活性。當然，在每個組織都需要依據自身的要求來平衡這兩者。標準的部署流程不只是更容易維護。它也使運維人員在壓力下更可靠的執行操作，相比於依照大量針對不同應用程序的不同版本的發布注記手工操作容易得多。標準部署流程也會讓自動化變得更簡單，讓運維人員從重複任務中解脫出來，同合適的訪問控制相結合，可以讓開發人員自己執行部署。如果有適合的集成點，將構建和發布系統連接起來實行持續部署以達到真正的端到端自動化也是有可能的。此外，實現更多的自動化部署流程來支持更複雜的場景，讓開發團隊在避免臨時流程時更加靈活性更容易。不過隨著自動化流程變得越來越複雜而難於實現和測試，是否采取複雜的自動化流程需要仔細考慮。但是相對手工流程明顯的優勢是，一旦自動化流程通過測試和校驗，你可以確保流程的所有步驟是執行結果是可預測的。對人們來說，不斷成功的執行複雜的、步驟眾多的流程的目標是非常難以達到的。