jenkins部署

隨著持續(xù)集成和持續(xù)交付的出現(xiàn) ，我們的構(gòu)建被分為不同的步驟，以創(chuàng)建部署管道。 這些步驟中的一些步驟可以是例如編譯和運行快速測試，運行慢速測試，運行自動驗收測試或發(fā)布應(yīng)用程序等。

部署流程的最后步驟意味著將我們的產(chǎn)品（如果是JEE項目，則是戰(zhàn)爭或耳朵 ）部署到類似生產(chǎn)的環(huán)境，用于UAT或發(fā)布產(chǎn)品時部署到生產(chǎn)系統(tǒng)。
在本文中，我們將了解如何配置Jenkins來正確管理Java Enterprise Application的部署。

要做的就是創(chuàng)建應(yīng)用程序，在這種情況下，在Java中一個非常簡單的Web應(yīng)用程序的第一件事情（其實只有一個JSP它打印一個Hello World！消息）和mavenize它來創(chuàng)建一個war文件（bar.war）時， 包目標(biāo)已執(zhí)行。

然后，我們需要創(chuàng)建一個Jenkins作業(yè)（稱為bar-web ），該作業(yè)負(fù)責(zé)編譯和運行單元測試。

完成此工作后，將進行其他工作，例如運行集成測試，運行更多測試，靜態(tài)代碼分析（即代碼質(zhì)量）或?qū)⒐ぜ蟼鞯焦ぜ鎯?#xff0c;但此處不會顯示。
最后，最后一步意味著將先前生成的代碼部署到暫存環(huán)境（例如，用于運行用戶驗收測試 ），并在關(guān)鍵用戶同意后將其部署到生產(chǎn)環(huán)境。
因此，讓我們看看如何在Jenkins中創(chuàng)建這些最終步驟。 請注意，在所有這些步驟中都必須使用在先前步驟中創(chuàng)建的二進制文件（在本例中為bar-web ）。 這是因為兩個原因，第一個是您的部署管道應(yīng)盡可能快地運行，并且顯然在每個步驟中編譯代碼并不是獲得代碼的最佳方法，第二個原因是每次您編譯源代碼時，增加了不被編譯為先前步驟的來源的機會。 為了實現(xiàn)此目標(biāo)，我們可以遵循兩種策略，第一種是將二進制文件上傳到工件存儲庫（例如Nexus或Artifactory ），然后在每個作業(yè)中從那里獲取。 第二個是使用復(fù)制工件 Jenkins插件來獲取上一步生成的二進制文件。

讓我們看看如何為第一種方法配置Jenkins 。

使用工件存儲庫方法，要求您從存儲庫下載我們要部署的版本，然后將其部署到外部環(huán)境； 在我們的案例中，部署到Web服務(wù)器。 所有這些步驟都是通過使用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>

然后，我們只需要創(chuàng)建一個名為bar-to-staging的新Jenkins作業(yè)即可運行cargo：redeploy Maven目標(biāo)，而Cargo插件將負(fù)責(zé)將bar-web部署到Web服務(wù)器。

這種方法具有一個優(yōu)點和一個缺點。 主要優(yōu)點是您不必局限于Jenkins ，可以單獨使用Maven ，也可以使用任何其他支持Maven的 CI 。 主要缺點是依賴于artefacts存儲庫，此計劃計劃了一個新問題，部署管道涉及許多步驟，并且在這些步驟之間（通常，如果您正在構(gòu)建快照版本），可以將新的artefact上傳到具有相同版本的artefacts存儲庫，并在管道執(zhí)行過程中使用它。 當(dāng)然，可以通過在人工制品存儲庫中管理權(quán)限來避免這種情況。

另一種方法是使用Jenkins插件，稱為copy-artifact-plugin 。 在這種情況下， Jenkins充當(dāng)人工制品存儲庫，因此，在不涉及任何外部存儲庫的情況下，將在下一步中使用在上一步中創(chuàng)建的工件。 使用這種方法，我們不能使用maven-cargo-plugin ，但是可以將deploy-jenkins-plugin與copy-artifacts-plugin結(jié)合使用。

因此，讓我們看看如何實現(xiàn)這種方法。

首先是創(chuàng)建一個Jenkins 構(gòu)建作業(yè) （ bar-web ），該作業(yè)將創(chuàng)建war文件。 請注意，定義了兩個Post-build動作 ，第一個是Archive the artifacts ，用于存儲生成的文件，因此復(fù)制工件插件可以將它們復(fù)制到另一個工作空間。 另一個是“ 構(gòu)建其他項目” ，在這種情況下，該項目調(diào)用一個作業(yè)，該作業(yè)負(fù)責(zé)將war文件部署到暫存目錄（ bar deploy-to-staging ）。

接下來是create bar deploy-to-staging構(gòu)建作業(yè)，其主要操作是將先前構(gòu)建作業(yè)生成的war文件部署到Tomcat服務(wù)器。

對于第二個構(gòu)建作業(yè)，您應(yīng)該配置復(fù)制工件插件以將以前生成的文件復(fù)制到當(dāng)前工作空間，因此在“ 構(gòu)建”部分的“ 從另一個項目復(fù)制工件”部分中，我們設(shè)置了要從哪個復(fù)制作業(yè)復(fù)制工件（在本例中） bar-web ）以及我們要復(fù)制的工件。 最后，在“構(gòu)建后操作”部分中 ，我們必須配置應(yīng)將哪個文件部署到Tomcat （ bar.web ），請記住該文件是以前的構(gòu)建作業(yè)所編譯和打包的，最后設(shè)置了Tomcat參數(shù)。 執(zhí)行管道如下所示：

請注意，已添加了第三個構(gòu)建作業(yè) ，該作業(yè)將war文件部署到生產(chǎn)服務(wù)器。

第二種方法是第一種方法的對立部分，您可以確保在管道的上一步中使用的偽像將在所有步驟中使用，但是您必須遵守Jenkins / Hudson的規(guī)定 。

因此，如果您要在人工制品存儲庫中創(chuàng)建策略，以便只有管道執(zhí)行程序可以將人工制品上載到存儲庫，則第一種方法更好，但是如果您不使用外部人工制品存儲庫（按原樣使用Jenkins ），則第二種方法是最好的方法是確保先前步驟中包裝的人工制品不會被并行步驟修改。

將文件部署到服務(wù)器后，可以毫無問題地執(zhí)行驗收測試或UAT測試。

我希望現(xiàn)在我們可以安全，更好地解決部署流程的最后步驟。

參考：在One Jar To Rulem All博客中，我們的JCG合作伙伴 Alex Soto 與Jenkins一起部署JEE工件 。

翻譯自: https://www.javacodegeeks.com/2012/09/jenkins-deploying-jee-artifacts.html

jenkins部署

總結(jié)

以上是生活随笔為你收集整理的jenkins部署_Jenkins：部署JEE工件的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。