服务 vs. 库
由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。
当团队在DevOps环境中工作时，开发人员负责一个功能的端到端：从服务客户到软件部署、从维护和支持。 这也给跨团队工作带来了挑战：对于发生在任何一个团队的错误，问题处理流程可能是不一样的。 源代码和部署的耦合给团队留下了这样的问题，在发生错误时，谁负责及时解决问题。 因此，即使在需求上有很大的重叠，团队也不愿意联合起来进行协作。
团队在一个微服务环境中工作。
大家是按照功能齐全的DevOps团队进行组织。每个团队负责他们端到端的贡献，包括维护服务、及时处理问题和客户支持。
一个团队的任务是向下游客户提供一个由其他团队构建的和现有服务类似的服务。
组织上的问题升级支持路径对每个团队来说可能是不同的。
每个团队的成员对于不影响自己下游客户的错误的线上问题并不愿意提供支持。
由于每个团队/客户关系的SLA定义不同，同一类型的错误的严重程度在团队之间可能不同。
团队可能有不同的安全或监管约束来管理他们的部署。
将源代码的责任与部署脱钩：两个团队都致力于准确识别重叠内容并进行协同。
只有共享的源代码被保留成为内源项目的一部分，大家分担责任。共享源代码应该是连贯的，它包括所有的测试代码（如果有的话，包括集成测试）和尽可能多的持续集成管道，以使得贡献验证更容易。
将配置和部署管道与实际业务逻辑解耦。为新的团队建立新的服务部署。
将团队间共用的内容以库（不是直接使用代码）的方式进行使用，并共享代码所有权（通过协商的方式进行修改）。
部署配置的内容可以作为单独的项目列入内源项目中，以允许团队讨论/协作或新团队复制这些配置代码。
团队开始愿意合作，并从分享实现业务逻辑的工作中获益。
一个原本专门为单一环境工作的服务，被转换成一个基于特定业务需求的更为通用的解决方案。
两个团队都了解他们各自的升级政策和部署设置，有可能为他们自己的设置找出改进。
需要对共享源代码进行修改的可能性增加，导致更频繁的机会来完善、改进和优化实施。
鼓励在发布包装、遥测、健康/准备就绪端点等方面逐步实现操作标准化，因为团队意识到，如果他们同意贯彻这些标准，就能更有效地在共享代码中维护这一点。
与这种模式相关的是30天保证模式，它采取了不同的方法来解决上述的约束问题。
Europace AG
Flutter 娱乐公司。一个Flutter 内源应用程序有一个共享的代码 "服务 "库，有跨团队的贡献和持续集成到流水线来构建和发布一个共享的发布工件。 每个采用的团队有一个 "部署配置 "库，定义他们自己的部署。这样方案满足了不同的监管要求、服务和事件管理实践以及不同业务领域的基础设施技能的需求。
Structured
Isabel Drost-Fromm
Rob Tuley
感谢Tobias Gesellchen在Europace AG 的内部评审。
服务 vs. 库: 这是内源，不是内部部署