我的组织已经启动了一个持续集成项目，以自动构建面向公众的大型网站。
“大”，我指的是30多个REST服务，外部CMS的内容和集成，以及几个ASP.NET前端。这些系统使用Java和C＃的混合编写，部署到Linux和Windows Server的混合框中。
我们遵循敏捷流程，与七个跨学科团队合作，所有团队都进行每周冲刺周期。
我们已经自动构建和部署了每项服务，但现在我们面临的挑战是自动化（当前手动）集成和最终验收测试。
我担心的是：
当服务更改合同及其消费者更新代码时会发生什么，但初始服务会进一步改变合同？我们/永远/将获得稳定的构建吗？
依赖性检查是手动系统中的一个噩梦，我看不出它在自动化系统中变得越来越好。 （我们在Java世界中使用Maven和Nexus，计划使用Ivy;我们正试图将.NET代码压缩到这里，结果很有趣。）
我们的测试有多深？他们应该多久运行一次？
答案 0 :(得分：3)
服务更改时会发生什么 它的合同和消费者更新 他们的代码，但最初的服务 进一步改变合同？我们会 /永远/获得稳定的构建？
在我看来，除了考虑持续集成之外，您还需要了解如何管理源代码管理系统。如果您有不同的团队在处理Web服务及其使用者，则可以在功能分支中完成该工作。一旦对Web服务合同的更改签入功能分支，就可以更新该服务的使用者，然后一旦在该功能分支上传递测试，就可以将其合并到主干中。
每次检查中继时都应自动运行测试，如果没有通过测试，则首要任务应该是解决问题。
依赖项的确切问题是什么？无论您是使用Maven还是Ivy，一旦为项目定义了依赖项，事情应该非常顺利。一旦你获得可重复的构建工作，持续集成就不会受到影响 - 当事情变得不同步时，它会更快地指出它。
答案 1 :(得分：1)
我个人一直在这种情况下。这不是一个容易解决的问题。
我真的希望您的网址包含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.如果你遵循上述原则，那么你将为每项服务更轻松地进行生产 - 它不会没有陷阱，但你会有很多基础。
请记住，您需要相信您的测试，因此请以应有的尊重对待测试！
答案 2 :(得分：0)
我认为从灵活应用程序基本功能的测试中获益很多，并且当服务合同更改破坏服务的客户时可能会中断。
每次将网站部署到集成测试环境时，都应运行这些测试（或至少是它们的“快速”子集）。全套至少每晚都会运行。
我认为您需要将该网站视为超级项目。如果有人更改了服务并打破了客户，则会导致网站部署标记为失败。通过跨所有项目的聚合更改日志，识别服务和负责的开发人员应该相对容易。
部署时，您通常会部署“网站”，这有效地在每个包含的服务，内容等上调用部署过程。或者只是更改位。
基本上，这就是作为一个组织，你要转变为要求服务足够稳定，以便与其他人的工作相结合。如果这是不可能的，他们会得到他们自己的分支，每个人都与先前的稳定版本相比，并且将在稍后的冲刺中与新版本的服务集成为高优先级故事。希望团队希望避免这种情况，并保留向后兼容的服务。
答案 3 :(得分：0)
我并不同意所选择的答案是最好的答案，因为它提到的功能分支应该是最后的手段（如果使用的话），因为它不能很好地与持续集成。对于某些最佳做法，我建议使用continuous delivery和continuous integration本书。