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

Question

我的组织已经启动了一个持续集成项目，以自动构建他们面向公众的大型网站。

“大”是指 30 多个 REST 服务、外部 CMS 的内容和集成，以及多个 ASP.NET 前端。这些系统是用 Java 和 C# 混合编写的，部署到 Linux 和 Windows Server 组合。

我们按照敏捷流程与七个跨学科团队合作，所有团队都按照每周的冲刺周期运行。

我们已经自动构建和部署每个单独的服务，但现在我们面临的挑战是自动化（目前是手动的）集成和最终验收测试。

我的担忧是：

• 当服务更改其合同并且其消费者更新其代码但初始服务进一步更改其合同时会发生什么？我们会/永远/获得稳定的构建吗？

• 依赖检查在手动系统中是一场噩梦，我看不出它在自动化系统中会变得更好。 （我们在 Java 世界中将 Maven 与 Nexus 结合使用，并计划使用 Ivy；我们正试图将 .NET 代码压缩到其中并产生有趣的结果。）

• 我们的测试应该有多深？他们应该多久跑一次？

Answer 1

服务更改时会发生什么 它的合同和它的消费者更新 他们的代码，但初始服务 进一步改变其合同？我们会 /曾经/获得稳定的构建？

在我看来，除了关注持续集成之外，您还需要关注如何管理源代码控制系统。如果您有不同的团队在处理 Web 服务及其消费者，那么这项工作可以在功能分支中完成。一旦对 Web 服务合同的更改签入到特性分支，就可以更新该服务的消费者，然后一旦该特性分支上的测试通过，它就可以合并到主干中。

每次检查到中继时都应该自动运行测试，如果它们没有通过，首要任务应该是修复破坏它们的任何东西。

依赖项到底有什么问题？无论您使用的是 Maven 还是 Ivy，一旦为您的项目定义了依赖项，事情就会变得非常顺利。一旦您让可重复的构建工作，持续集成在这里就不会受到伤害 - 它会通过在事情不同步时更快地指出来帮助。

Answer 2

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

我非常希望您的 URL 包含 API 版本。

在 SOA 环境中工作时的一般原则如下。 1. 次要（增量和非破坏性 API）更改不会强制使用主要 API 版本。 2. 应用程序必须同时支持版本 N 和 N+1，直到所有消费应用程序都升级。 3. 可以“暗发布”那些为 API 的 N+1 版本“准备好”但尚未处理来自消费应用程序的版本 N+1 请求的应用程序。 4. 请记住尽快弃用旧 API 版本。
5. 如果一个小的增量更改破坏了服务，那么解析请求就会出现问题 - 某些 Java 非编组实现真的很糟糕 - 主要版本更改可能是解决这个问题的唯一方法，必然违反第 1 点。 6. 再多的自动化比相关团队之间的良好沟通和计划更容易实施。 7. 确保您有回归测试证明版本 N 仍然有效，并且版本 N+1 在集成环境中也有效。 8. 服务的优雅降级是最重要的。如果下游服务不可用，则告诉客户端请求未处理，他们应稍后重新提交。任何其他解决方案都需要在您的应用程序中加载更复杂的负载 - 在这种情况下考虑使用消息队列。 8. 每个组件在发布之前都应该通过管道单独测试。一般经验法则：
第 1 阶段：构建/单元测试/隔离集成测试。
第 2 阶段。使用模拟的下游服务进行部署和测试。
阶段 3. 在全集成环境中部署和测试。请注意，如果正在部署另一个服务，测试可能会失败。 第 4 阶段。第 3 阶段的手动健全性检查部署。 阶段 5. 性能/安全检查。 第 6 阶段。手动接受构建以部署到生产中。 9. 如果您遵循上述原则，那么您的每项服务都可以更轻松地投入生产 - 并非没有陷阱，但您将覆盖很多基础。

请记住，您需要信任您的测试，因此请以应有的尊重对待测试！

Answer 3

我认为你会从灵活应用基本功能的测试中获益良多，并且在服务合同更改破坏服务客户时可能会中断。

每次将网站部署到集成测试环境时，都应运行这些测试（或至少其中的“快速”子集）。全套至少每晚运行一次。

我认为您需要将网站视为超级项目。如果有人更改服务并破坏客户，则会导致网站的部署被标记为失败。通过所有项目的汇总变更日志，确定负责的服务和开发人员应该相对容易。

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

基本上，这意味着作为一个组织，您需要转变为要求服务足够稳定，以便可以与其他所有人的工作集成。如果这是不可能的，他们会建立自己的分支，每个人都针对以前的稳定版本工作，并将与新版本的服务集成，作为以后 sprint 中的高优先级故事。希望团队希望避免这种情况并保留向后兼容的服务。

Answer 4

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