SOA中的持续交付

-1

持续交付如何馈送到SOA体系结构中？SOA中的持续交付

由于每个SOA服务应该是独立的，这是否意味着我们需要每个服务的单独管道？当有100多种服务时，这会如何影响？

我们可以将服务分组为可部署单元来分组服务。

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

有没有一个模型基于此？

2015-02-23 IanWatson

这真的取决于我的猜测。在一个组织中，他们拥有不同的测试方法，具体取决于这些服务在SOA目录中的位置。例如，技术服务（如发送邮件服务）已经进行了独立测试，帐户级服务和SAP级服务通常作为一组进行测试以减轻负载。这完全取决于您的SOA治理策略。如果没有这些地方......它会变得凌乱。 – Namphibian 2015-02-24 21:56:13

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

来源

2015-03-31 03:27:34

我看不到100个独立管道是如何管理的。尤其是在服务之间存在依赖关系的情况下，如编排服务。 – IanWatson 2015-03-31 11:42:07

我们有40个不同的服务，我们的部署是动态的，以处理个别服务部署。诀窍是拥有一个通用的部署代码，这样你只需要传入一个服务名称作为参数，其余的流程就会自动完成。您甚至可以使用基于容器（例如docker）的部署来实现此目的 – 2015-03-31 14:30:57

就持续交付而言，当我想推送发行版时，可能会在不同服务上进行多项更改。说我们有＃1 - 服务A更新＃2 - 服务B更新＃3 - 服务C更新我想在点击按钮，释放从以前版本的所有变化。例如，如果以前的版本是＃1，并且＃2和＃3可用。我想单击包含＃2和＃3的“build＃3”（自上次发布以来的所有更改）我不明白这是不同管道的“可用”。 – IanWatson 2015-03-31 20:16:00

SOA中的持续交付

回答

相关问题