大型持续集成的最佳实践是什么[关闭]

当服务发生变化时会发生什么 它的合同和消费者都在更新 他们的代码,但最初的服务 进一步修改合同?我们会吗 /曾经/得到过稳定的体形吗?

在我看来,除了考虑持续集成之外,您还需要考虑如何管理源代码管理系统。如果您有不同的团队处理web服务及其使用者,那么这些工作可以在功能分支中完成。一旦web服务契约的更改签入到功能分支中,该服务的使用者就可以更新,然后一旦该功能分支上的测试通过,它就可以合并到主干中。

每次对主干进行签入时,测试都应该自动运行,如果测试没有通过,首要任务应该是修复任何损坏测试的地方。

依赖项的具体问题是什么?无论您使用的是Maven还是Ivy,一旦为项目定义了依赖项,事情就会变得非常顺利。一旦你得到了一个可重复的构建,持续集成在这里就不会有什么坏处——当事情变得不同步时,它会更快地指出问题所在。

我个人也经历过这种情况。这不是一个容易解决的问题。

我真的希望你的URL包含API版本。

在SOA环境中工作时的一般原则如下。 1.次要(增量和非破坏性API)更改不会强制使用主要API版本。 2.应用程序必须同时支持版本N和N+1,直到所有消费应用程序升级。 3.可以“暗发布”API版本N+1的“准备就绪”应用程序,但尚未处理消费应用程序的版本N+1请求。 4.记住尽快弃用较旧的API版本。
5.如果一个小的增量更改破坏了一个服务,那么解析请求就有问题了——某些Java反编组实现在这方面真的很糟糕——一个大的版本更改可能是解决这个问题的唯一方法,必然会违反第1点。 6.相关团队之间的良好沟通和规划比任何自动化都更容易实施。 8.服务质量的下降至关重要。如果下游服务不可用,则告诉客户端请求未得到处理,他们应稍后重新提交。任何其他解决方案都需要在应用程序中加载更复杂的信息——在这种情况下考虑消息队列。 8.每个组件在释放前应通过管道进行单独测试。一般经验法则:

阶段2.使用模拟的下游服务部署和测试。
第4阶段。第3阶段中的手动健全性检查部署。 阶段5.性能/安全检查。 9.如果你遵循上述原则,那么你的每项服务都会更容易投入生产——这不是没有陷阱,但你会有很多基础。

请记住,您需要信任您的测试,所以请以应有的尊重对待测试!

我认为你会从测试中受益匪浅,这些测试可以灵活地使用应用程序的基本功能,并且当服务合同的变更破坏了服务的客户时,这些测试很可能会中断。

每次将网站部署到集成测试环境时,都应该运行这些测试(或至少是其中的“快速”子集)。整套设备将至少每晚运行。

当您部署时,您通常会部署“网站”,它有效地调用每个包含的服务、内容等的部署过程,或者可能只是更改的部分。

我不同意选择的答案是最好的,因为它提到了按功能进行分支,这应该是最后的手段(如果使用的话),因为它不能很好地进行持续集成。对于一些最佳实践,我推荐 continuous delivery 和 continuous integration