SOA 中的持续交付答案

【问题标题】：Continuous Delivery in SOASOA 中的持续交付
【发布时间】：2015-02-23 20:20:46
【问题描述】：

持续交付如何融入 SOA 架构？

由于每个 SOA 服务都应该是独立的，这是否意味着我们需要为每个服务提供单独的管道？当有 100 个服务时，这会产生什么影响？

我们可以将服务分组为可部署的单元以对服务进行分组。

我看到的最大问题是在 100 种不同版本配置设置中的测试。

有没有模型可以以此为基础？

【问题讨论】：

这真的取决于我猜。在一个组织中，根据这些服务在 SOA 目录中的位置，他们有不同的测试方法。例如，技术服务，即发送邮件服务是独立测试的，账户级服务和 SAP 级服务大多作为一个组进行测试，以减轻负载。这一切都取决于您的 SOA 治理策略。如果没有这些，它会很快变得一团糟。

【解决方案1】：

如果您有一个服务松散耦合的微服务架构，那么理想情况下，您应该拥有可以“黑盒”测试已更改的单个服务的集成测试。在这种情况下，您可以轻松地为每个服务构建单独的管道。您真的不想每次更改 1 或 2 个组件时部署 100 个不同的组件
通过单独的管道，我并不是指每个服务的单独部署代码库。您可以概括您的容器和服务，以便可以自动化部署代码。
在进行配置时，您应该使用 restful 框架分离出 SOA。在这种情况下，组件和组件之间没有紧密耦合 range f 烟雾测试可以轻松确定特定服务的产品部署是否成功

【讨论】：

我不明白拥有 100 个单独的管道是如何管理的。尤其是在服务之间存在依赖关系的情况下，例如编排服务。
我们有 40 种不同的服务，我们的部署是动态的以处理单个服务部署。诀窍是有一个通用的部署代码，这样您只需要传入一个服务名称作为参数，其余的流程就会为您自动完成。您甚至可以使用基于容器（例如 docker）的部署来实现这一目标
在持续交付方面，当我想推送一个版本时，不同的服务可能会有一些变化。假设我们有 #1 - 服务 A 已更新 #2 - 服务 B 已更新 #3 - 服务 C 已更新我想单击一个按钮，释放上一个版本的所有更改。例如，如果以前的版本是#1，并且#2 和#3 可用。我想单击“build #3”，其中将包括 #2 和 #3（自上次发布以来的所有更改）我看不出这对于不同的管道如何“可行”。