介绍

当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