What happens when a service changes its contract and its consumers update their code, but the initial service further changes its contract? Will we /ever/ get a stable build?
It sounds to me that in addition to looking at continuous integration, you need to be looking at how you are managing your source control system. If you have different teams working on the web service and its consumers, that work could be done in a feature branch. Once the changes to the web service contract were checked in to the feature branch, the consumers of that service could be updated, and then once tests passed on that feature branch, it could be merged in to the trunk.
Tests should be run automatically every time a check in is done to trunk, and if they don't pass, the first priority should be to fix whatever broke them.
What exactly are the issues with the dependencies? Whether you are using Maven or Ivy, once you have the dependencies defined for your projects things should be pretty smooth. Continuous integration won't hurt here once you get a repeatable build working - it will help by pointing out more quickly when things are getting out of synch.
I've personally been in this scenario. This isn't an easy problem to solve.
I seriously hope your URL'S contain an API version.
General principles as follows when working in an SOA environment. 1. Minor (incremental and non-breaking API) changes don't force a major api version. 2. Applications must support versions N and N+1 simultaneously until all consuming applications have upgraded. 3. It's okay to "dark-release" applications which are "ready" for version N+1 of the API, but are not yet handling version N+1 requests from consuming applications. 4. Remember to deprecate older API versions as soon as possible. 5. If a minor incremental change breaks a service, then there's a problem with parsing the request - certain Java un-marshalling implementations really suck at this - a Major version change might be your only way around this problem, necessarily contravening point 1. 6. No amount of automation will make it easier to implement than good communication and planning between relevant teams. 7. Make sure you have regression tests proving version N still works, and that version N+1 works too, in an integration environment. 8. Graceful degradation of service is paramount. If a downstream service is unavailable, then tell the client the request was not handled and they should re-submit later. Any other solution will require loads more complexity in your apps - consider an Message Queue in this instance. 8. Each component should be individually tested through the pipeline before it's released. General rule of thumb: Phase 1: Build/Unit Test / isolated integration tests. Phase 2. Deploy and test using mocked downstream services. Phase 3. Deploy and test in a full-integration environment. Be aware that tests might fail if another service is being deployed. Phase 4. Manual sanity check deployment in phase 3. Phase 5. Performance/Security checks. Phase 6. Manual acceptance of build to deploy into production. 9. If you follow the above principles, then you'll have an easier ride into production for each of your services - it won't be without pitfalls, but you'll have a lot of bases covered.
Remember you'll need to trust your tests, so treat testing with the respect it deserves!
I think you'd benefit quite a lot from tests that flex the basic functionality of the app and are likely to break when service contract changes break the service's customers.
These tests (or at least a 'fast' subset of them) should be run every time you deploy your website to an integration test environment. The full set would run at least nightly.
I think you need to view the website as super-project. If someone changes a service and breaks the customers, it will cause the deployment of the website to be marked as failed. With an aggregated change log across all the projects, identifying the service and developer responsible should be relatively easy.
When you deploy, you'll usually deploy "the website" which is effectively calling the deployment process on each of the included services, content, etc. Or perhaps just the changed bits.
Basically, what this gets to is that as an organization, you make a shift to requiring that services are stable enough that they can be integrated in with everyone else's work. If that isn't possible, they get their own branch and everyone works against the previous stable version and will have integrating with a new version of the service as a high priority story in a later sprint. Hopefully the teams want to avoid that and leave backwards compatible services available.
I don't agree that the selected answer is the best one because it mentions branching by feature which should be a last resort (if used at all) as it doesn't play nice with continuous integration. For some best practices I recommend the continuous delivery and continuous integration books.
发布评论
评论（4）
在我看来，除了关注持续集成之外，您还需要关注如何管理源代码控制系统。如果您有不同的团队致力于 Web 服务及其使用者，那么这项工作可以在功能分支中完成。一旦对 Web 服务契约的更改签入到功能分支，该服务的使用者就可以更新，然后一旦测试在该功能分支上通过，就可以将其合并到主干中。
每次对主干进行签入时都应自动运行测试，如果未通过，则首要任务应该是修复损坏它们的任何内容。
依赖关系究竟存在哪些问题？无论您使用 Maven 还是 Ivy，一旦为项目定义了依赖项，事情就会非常顺利。一旦你得到一个可重复的构建工作，持续集成不会有什么坏处——当事情不同步时，它会更快地指出来，从而有所帮助。
It sounds to me that in addition to looking at continuous integration, you need to be looking at how you are managing your source control system. If you have different teams working on the web service and its consumers, that work could be done in a feature branch. Once the changes to the web service contract were checked in to the feature branch, the consumers of that service could be updated, and then once tests passed on that feature branch, it could be merged in to the trunk.
Tests should be run automatically every time a check in is done to trunk, and if they don't pass, the first priority should be to fix whatever broke them.
What exactly are the issues with the dependencies? Whether you are using Maven or Ivy, once you have the dependencies defined for your projects things should be pretty smooth. Continuous integration won't hurt here once you get a repeatable build working - it will help by pointing out more quickly when things are getting out of synch.
我个人就经历过这种情况。这不是一个容易解决的问题。
我真诚地希望您的 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. 如果您遵循上述原则，那么您的每项服务都会更容易投入生产——这不会没有陷阱，但您将覆盖很多基础。
请记住，您需要信任您的测试，因此请以应有的尊重对待测试！
I've personally been in this scenario. This isn't an easy problem to solve.
I seriously hope your URL'S contain an API version.
General principles as follows when working in an SOA environment.
1. Minor (incremental and non-breaking API) changes don't force a major api version.
2. Applications must support versions N and N+1 simultaneously until all consuming applications have upgraded.
3. It's okay to "dark-release" applications which are "ready" for version N+1 of the API, but are not yet handling version N+1 requests from consuming applications.
4. Remember to deprecate older API versions as soon as possible.
5. If a minor incremental change breaks a service, then there's a problem with parsing the request - certain Java un-marshalling implementations really suck at this - a Major version change might be your only way around this problem, necessarily contravening point 1.
6. No amount of automation will make it easier to implement than good communication and planning between relevant teams.
7. Make sure you have regression tests proving version N still works, and that version N+1 works too, in an integration environment.
8. Graceful degradation of service is paramount. If a downstream service is unavailable, then tell the client the request was not handled and they should re-submit later. Any other solution will require loads more complexity in your apps - consider an Message Queue in this instance.
8. Each component should be individually tested through the pipeline before it's released. General rule of thumb:
Phase 1: Build/Unit Test / isolated integration tests.
Phase 2. Deploy and test using mocked downstream services.
Phase 3. Deploy and test in a full-integration environment. Be aware that tests might fail if another service is being deployed.
Phase 4. Manual sanity check deployment in phase 3.
Phase 5. Performance/Security checks.
Phase 6. Manual acceptance of build to deploy into production.
9. If you follow the above principles, then you'll have an easier ride into production for each of your services - it won't be without pitfalls, but you'll have a lot of bases covered.
Remember you'll need to trust your tests, so treat testing with the respect it deserves!
我认为您将从测试中受益匪浅，这些测试可以灵活应用程序的基本功能，并且当服务合同更改破坏服务的客户时可能会中断。
每次将网站部署到集成测试环境时，都应该运行这些测试（或至少其中的“快速”子集）。全套至少每晚运行一次。
我认为您需要将该网站视为超级项目。如果有人更改了服务并破坏了客户，就会导致网站的部署被标记为失败。通过所有项目的汇总变更日志，识别负责的服务和开发人员应该相对容易。
部署时，您通常会部署“网站”，该网站有效地调用每个包含的服务、内容等的部署过程。或者可能只是更改的部分。
基本上，这意味着作为一个组织，您需要转变为要求服务足够稳定，以便它们可以与其他人的工作集成。如果不可能，他们会获得自己的分支，每个人都针对之前的稳定版本进行工作，并将与新版本的服务集成作为后续冲刺中的高优先级故事。希望团队希望避免这种情况并保留向后兼容的服务。
I think you'd benefit quite a lot from tests that flex the basic functionality of the app and are likely to break when service contract changes break the service's customers.
These tests (or at least a 'fast' subset of them) should be run every time you deploy your website to an integration test environment. The full set would run at least nightly.
I think you need to view the website as super-project. If someone changes a service and breaks the customers, it will cause the deployment of the website to be marked as failed. With an aggregated change log across all the projects, identifying the service and developer responsible should be relatively easy.
When you deploy, you'll usually deploy "the website" which is effectively calling the deployment process on each of the included services, content, etc. Or perhaps just the changed bits.
Basically, what this gets to is that as an organization, you make a shift to requiring that services are stable enough that they can be integrated in with everyone else's work. If that isn't possible, they get their own branch and everyone works against the previous stable version and will have integrating with a new version of the service as a high priority story in a later sprint. Hopefully the teams want to avoid that and leave backwards compatible services available.
我不同意所选答案是最好的答案，因为它提到按功能进行分支，这应该是最后的手段（如果使用的话），因为它与持续集成效果不佳。对于一些最佳实践，我建议使用持续交付和持续交付。 com/books/duvall.html" rel="nofollow">持续集成书籍。
I don't agree that the selected answer is the best one because it mentions branching by feature which should be a last resort (if used at all) as it doesn't play nice with continuous integration. For some best practices I recommend the continuous delivery and continuous integration books.