大型持续集成的最佳实践是什么？

Question

我的组织已经开始了一个持续集成项目，以自动构建他们的大型面向公众的网站。 “大”，我的意思是30 + REST服务，内容和外部CMS的集成，以及几个ASP.NET前端。这些系统使用Java和C＃混合编写，部署到Linux和Windows Server服务器组合框中。

我们通过七个跨学科团队开展敏捷流程，所有团队都运行到每周冲刺周期。我们有自动构建和部署每个单独的服务，但现在我们面临的挑战是自动化（当前手动）集成和最终验收测试。

我的担忧是：

• 当服务改变其合同和消费者更新自己的代码，但最初的服务进一步改变其合同会发生什么？我们会/永远/得到一个稳定的构建？

• 依赖检查是手动系统中的噩梦，我看不到它在自动化系统中变得更好。 （我们在Java世界中使用带有Nexus的Maven，并计划使用Ivy;我们试图用有趣的结果将.NET代码压缩到此。）

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

Answer 1

当服务改变 其合同和消费者更新 他们的代码，但最初的服务 进一步改变其合同会发生什么？我们 /永远/得到稳定的构建？

听起来，除了持续集成之外，您还需要考虑如何管理源代码管理系统。如果您有不同的团队负责Web服务及其使用者，那么可以在功能分支中完成这项工作。一旦将Web服务合同的更改签入功能分支，该服务的使用者就可以更新，然后一旦在该功能分支上进行测试，就可以将其合并到中继。

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

什么是依赖关系的问题？无论您是使用Maven还是常春藤，只要您有为项目定义的依赖关系，事情就会非常顺利。一旦你获得了可重复的构建工作，持续集成不会在这里受到伤害 - 当事情失去同步时，这将有助于更快速地指出。

Answer 2

我想你会从测试中受益颇多，这些测试会弯曲应用程序的基本功能，并有可能在服务合同变更破坏服务的客户时中断。

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

我认为你需要将网站视为超级项目。如果有人更改服务并中断了客户，则会导致网站的部署被标记为失败。通过在所有项目中汇总更改日志，识别服务和开发人员应该相对容易。

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

基本上，作为一个组织，你需要转变到要求服务足够稳定，以便能够与其他人的工作相结合。如果这不可能，他们会得到自己的分支，每个人都会违背之前的稳定版本，并将在稍后的冲刺中与新版本的服务集成为高优先级的故事。希望这些团队想要避免这种情况，并留下向后兼容的服务。

Answer 3

我个人一直在这种情况下。这不是一个容易解决的问题。

我真的很希望你的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.优雅的服务退化是至关重要的。如果下游服务不可用，请告诉客户端请求未处理，并且稍后应重新提交。任何其他解决方案都需要在您的应用程序中加载更复杂的内容 - 在此实例中考虑Message Queue。 8.每个组件在发布之前都应该通过管道进行单独测试。一般经验法则：
阶段1：构建/单元测试/隔离集成测试。
阶段2.使用模拟的下游服务进行部署和测试。
阶段3.在完全集成的环境中部署和测试。请注意，如果正在部署其他服务，测试可能会失败。 阶段4.阶段3中的手动健全性检查部署。 阶段5.性能/安全检查。 阶段6.手动接受构建以部署到生产环境中。 9.如果你遵循上述原则，那么你的每一项服务都会更容易地投入生产 - 它不会没有陷阱，但是你将拥有很多基础。

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

Answer 4

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