部署流程的最后一步意味著將我們的產品(如果是JEE項目,則是戰爭或耳朵 )部署到類似生產的環境,用于UAT或在產品發布時部署到生產系統。
在本文中,我們將了解如何配置Jenkins來正確管理Java Enterprise Application的部署。
要做的就是創建應用程序,在這種情況下,在Java中一個非常簡單的Web應用程序的第一件事情(其實只有一個JSP它打印一個Hello World!消息)和mavenize它來創建一個war文件(bar.war)時, 包目標已執行。
然后,我們需要創建一個Jenkins作業(稱為bar-web ),該作業負責編譯和運行單元測試。
完成此工作后,將進行其他工作,例如運行集成測試,運行更多測試,靜態代碼分析(即代碼質量)或將工件上傳到工件存儲庫,但此處不會顯示。
最后,最后一步意味著將先前生成的代碼部署到暫存環境(例如,用于運行用戶驗收測試 ),并在關鍵用戶同意后將其部署到生產環境。
因此,讓我們看看如何在Jenkins中創建這些最終步驟。 請注意,在所有這些步驟中必須使用在先前步驟中創建的二進制文件(在本例中為bar-web )。 這是由于兩個原因,第一個原因是您的部署管道應盡可能快地運行,并且顯然在每個步驟中編譯代碼并不是獲得代碼的最佳方法,第二個原因是每次您編譯源代碼時,增加了不被編譯為先前步驟的來源的機會。 為了實現此目標,我們可以遵循兩種策略,第一種是將二進制文件上傳到工件存儲庫(例如Nexus或Artifactory ),然后在每個作業中從那里獲取。 第二個是使用復制工件 Jenkins插件來獲取上一步生成的二進制文件。
讓我們看看如何為第一種方法配置Jenkins 。
使用工件存儲庫方法,要求您從存儲庫下載我們要部署的版本,然后將其部署到外部環境; 在我們的案例中,部署到Web服務器。 所有這些步驟都是通過使用maven-cargo-plugin完成的 。
<build><plugins><plugin><groupId>org.codehaus.cargo<groupId><artifactId>cargo-maven2-plugin<artifactId><version>1.0<version><!-- Container configuration --><container><containerId>tomcat6x<containerId><type>remote<type><container><configuration> <type>runtime<type><properties><cargo.remote.username>admin<cargo.remote.username><cargo.remote.password><cargo.remote.password><cargo.tomcat.manager.url>http:localhost:8888manager<cargo.tomcat.manager.url><properties><configuration><deployer><deployables><deployable><groupId>com.lordofthejars.bar<groupId><artifactId>bar-web<artifactId><type>war<type><deployable><deployables><deployer><plugin><plugins><build><dependencies><dependency><groupId>com.lordofthejars.bar<groupId><artifactId>bar-web<artifactId><type>war<type><version>${target.version}<version><dependency><dependencies>
然后,我們只需要創建一個名為bar-to-staging的新Jenkins作業即可運行cargo:redeploy Maven目標,而Cargo插件將負責將bar-web部署到Web服務器。
這種方法有一個優點和一個缺點。 主要優點是您不必局限于Jenkins ,可以單獨使用Maven ,也可以使用任何其他支持Maven的 CI 。 主要缺點是依賴于artefacts存儲庫,并且此計劃是一個新問題,部署管道涉及許多步驟,并且在這些步驟之間(通常,如果您正在構建快照版本),可以將新的artefact上傳到具有相同版本的artefacts存儲庫,并在管道執行過程中使用它。 當然,可以通過在人工制品存儲庫中管理權限來避免這種情況。
另一種方法是使用Jenkins插件,稱為copy-artifact-plugin 。 在這種情況下, 詹金斯(Jenkins)充當人工制品存儲庫,因此在下一步中使用在上一步中創建的工件,而無需涉及任何外部存儲庫。 使用這種方法,我們不能使用maven-cargo-plugin ,但是可以將deploy-jenkins-plugin與copy-artifacts-plugin結合使用。
因此,讓我們看看如何實現這種方法。
首先是創建一個Jenkins 構建作業 ( bar-web ),該作業將創建war文件。 請注意,定義了兩個構建后操作 ,第一個是Archive the artifacts ,用于存儲生成的文件,因此復制工件插件可以將它們復制到另一個工作空間。 另一個是“ 構建其他項目” ,在這種情況下,該項目調用一個作業,該作業負責將war文件部署到登臺目錄( bar deploy-to-staging )。
接下來是創建欄從部署到分段構建作業,其主要操作是將先前構建作業生成的war文件部署到Tomcat服務器。
對于第二個構建作業,您應該配置復制工件插件以將以前生成的文件復制到當前工作空間,因此在“ 構建”部分的“ 從另一個項目復制工件”部分中,我們設置了要從哪個復制作業復制工件(在本例中) bar-web )以及我們要復制的工件。 最后,在“構建后操作”部分中 ,我們必須配置應將哪個文件部署到Tomcat ( bar.web ),請記住該文件是以前的構建作業所編譯和打包的,最后設置了Tomcat參數。 執行管道如下所示:
請注意,已添加了第三個構建作業 ,該作業將war文件部署到生產服務器。
第二種方法是第一種方法的對立部分,您可以確保在管道的上一步中使用的偽像將在所有步驟中使用,但是您必須遵守Jenkins / Hudson的規定 。
因此,如果您要在人工制品存儲庫中創建策略,以便只有管道執行程序可以將人工制品上載到存儲庫,則第一種方法更好,但是如果您不使用外部人工制品存儲庫(按原樣使用Jenkins ),則第二種方法是最好的方法是確保先前步驟中包裝的人工制品不會被并行步驟修改。
將文件部署到服務器后,可以毫無問題地執行驗收測試或UAT測試。
我希望現在我們可以安全,更好地解決部署流程的最后步驟。
參考:在One Jar to Rulem All博客中,我們的JCG合作伙伴 Alex Soto 與Jenkins一起部署JEE工件 。
翻譯自: https://www.javacodegeeks.com/2012/09/jenkins-deploying-jee-artifacts.html