介紹

當ADF應用程序建立在共享庫之上時，有一種非常流行的架構模式。 因此，主應用程序被部署為EAR，并且所有子系統都在共享庫中實現，這些共享庫可以在“熱”模式下獨立構建并作為JAR部署到WebLogic，而無需停機。 這種方法的優點似乎很明顯：

• 它分解了實現模塊化和重用概念的應用程序
• CI / CD流程可能會更快，因為將只重建/重新部署一個庫
• 重新部署共享庫沒有停機時間

看起來太酷了，人們可以在新項目中選擇這種架構模式，并且對實現應用程序時所做出的決定感到非常滿意。 當他們投入生產時，他們會變得更加高興，因為他們可以輕松地修復大多數錯誤并實施新的要求，從而避免完全重新部署且沒有任何停機時間。

毫無疑問，在投入生產之前，任何更改（以及相應的共享庫）都應在以前的環境（例如QA，UAT等）中進行部署和測試。

一段時間內，沒有人確切知道每種環境中部署了什么版本的共享庫。 支持這種應用程序并在這種情況下實現新的更改有些棘手，因為即使它在這種環境下也可以工作，但由于共享庫的組合可能有所不同，因此無法保證它將在下一個環境中正常工作。 如果它是一個大型應用程序，并且有許多共享庫，那么這可能會成為一場噩夢，而且很多時候人們只是放棄重新部署所有內容，最終回到整體EAR。 并不是很酷，但是至少他們現在可以再次入睡了。

解

在這篇文章中，我將展示如何整理事物，并建立一個使用FlexDeploy在共享庫之上構建的ADF應用程序的連續交付過程。 FlexDeploy是一個快速增長的自動化和DevOps解決方案，如果您想了解所有內容，請隨時訪問該網站 。 在這里，我將專注于FlexDeploy如何通過引入快照和管線的概念，共享庫幫助。

快照是代表整個系統的一組可部署工件。 如果要重建其中任何一個工件，那么將創建一個新快照，其中包含該工件的新版本以及其余工件的先前版本。 在我們的情況下，快照將包含用于主ADF應用程序的EAR和用于共享庫的JAR。

為了為我們的應用程序創建快照，FlexDeploy應該知道它的全部內容和組成的項目。 FlexDeploy中有一個“ 發布”概念，它是一堆項目，應將其內置到快照中，并在整個環境中作為一個單元一起部署。

在我們的示例中，有3個項目-一個作為主應用程序，兩個針對部門和員工任務流，部署為共享庫。 每個項目都在FlexDeploy中單獨配置，每個項目“知道”如何獲取其源代碼，如何構建和部署（FlexDeploy使用工作流進行構建和部署，但這是另一個重要的故事，遠遠超出了本文）。

完成所有定義后，只要開發人員為版本中包含的任何項目推動代碼更改，FlexDeploy都會構建一個新快照。 它僅重建那些已更改的項目（生產耳朵和罐子），其余工件原樣包含在新快照中。

好的，現在我們可以構建快照并將其部署到整個環境中。 版本定義是指管道。

管道是一種確保嚴格按照預定順序在整個環境中部署整個快照的方法。 這意味著只能以Dev-> QA-> Prod的順序（如果以此方式定義了管道）來部署此快照（換句話說，ear / jar版本的這種組合）。 如果在Dev和QA上不成功，那就無法進入Prod。 管道由涉及環境的各個階段組成，每個階段均由多個門（批準，測試結果等）組成，這意味著快照在此環境下進行處理之前應先通過所有門）和步驟（部署，運行自動測試，通知，手動步驟） ，…）。

因此，基本上，部署只是管道階段（環境）中的一個管道步驟。 此步驟足夠聰明，可以僅重新部署已更改的工件（除非將該步驟配置為執行“強制”部署）。 FlexDeploy跟蹤在每個環境中已部署了哪些工件版本。

總結一下，我想說的是，當將FlexDeploy用作具有共享庫的ADF應用程序的DevOps解決方案時，我們一方面獲得了該架構模式的所有好處，另一方面我們可以使事情井井有條，確切知道已部署了哪種組合跨環境，什么已經過測試，可以投入使用，什么失敗了。

而已！

翻譯自: https://www.javacodegeeks.com/2017/12/continuous-delivery-adf-applications-weblogic-shared-libraries.html

總結

以上是生活随笔為你收集整理的使用WebLogic共享库连续交付ADF应用程序的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。