问敏捷方法( CI/CD )如何应用于拥有100/1000 s开发人员的大型整体软件项目？

EN

那么，您将无法将敏捷方法应用于大型团队。通常的原则之一是在比萨团队工作(少于10个人，他们可以一起分享一个大比萨饼)，因为敏捷过程所提倡的形式主义使得它很难适用于一个大型团队，信息会分散，有些会在人群中丢失。

因此，在考虑CI系统之前，您必须检查您构建的软件周围的组织。

这主要需要以较小的独立部分重构一个大型项目，这可以是单独的软件(您将采用微服务的方式)，也可以是软件中的体系结构设计，其中一个类/对象/库提供给一个小团队。这个团队必须记录它的服务输入和输出(服务合同/服务导向)。

一旦完成这一任务，您就可以将每个独立部分的责任分配给一个较小的团队，该团队将能够应用敏捷过程。

这可能解决了CI/CD问题，分割代码库将允许每个团队遵循自己的进度，只要它的接口是正确的版本，并且输入/输出是为某种类型的调用而固定的，您可以使产品的某些部分保持先前的行为。

主要的缺点是来自每个部分的服务契约必须在使用的版本之间兼容，这需要依赖系统知道哪个部分在放弃未使用的API版本之前使用哪个版本的内容。这就带来了打破改变的问题，而且通常需要生产者和消费者之间进行仔细的横向规划。

我们从一个大型的、单块的后端应用程序，到100年代的devs开发到基于码头的微服务，使用ansible和类似的DevOps fluff进行部署。下面是关于这个过程的一些注意事项：

1. 确定您的单块应用程序中的域边界。确保边界之间的调用尽可能少(我指的是进程内调用或数据库访问)。
2. 将开发人员分成几个小组，并为每个开发人员分配一个域的一部分。(有可能一个域也将在多个团队中工作)
3. 指定仍然发生的越界调用，并在其周围定义一个API。确保在执行跨域调用时只使用此中间库。
4. 对这些中间库进行适当的测试，检查它们是否正常工作。
5. 根据这些域划分代码。

现在，您的每个团队都应该更小，并且在编写它们的代码时不要过于担心其他的代码。您在这些中间库中进行的测试应该包含来自外部调用方的回归，内部代码是您的责任。显然，如果中间库需要更改，或者您的测试告诉您不再遵守API规范(这种情况可能也会发生)，那么您需要开始使用这些API与其他团队(S)交谈。

一旦您感到满意，就可以尝试将这些中间库替换为HTTP调用，而不是进程内调用。一旦完成，你实际上可以把你的大型应用分成真正的、更小的部分(它们可能仍然不是“微”服务，而是更小、更易于管理)。此外，它们至少属于一个特定的领域，也有一个清晰、定义良好的API，其他人(包括新的微服务，大部分不使用遗留的大型应用程序)可以使用它来获取他们的数据。

是的，把更大的团队分成更小、更敏捷的子团队显然是必要的。但是，在更大的团队层面上，做整体表现还远远不够。

有了高度可伸缩的CI系统，即使是非常大的团队也有可能在单个主分支中使用基于主干的集成，从而完全避免与其合并相关的中间集成分支和未知/风险/延迟/成本，否则这将成为影响子团队的严重障碍。请参阅如何对大型项目/团队进行持续集成？

有了这些障碍，子团队才能真正充分利用敏捷技术，因为它们都在同一个页面上，并且受益于CI方法的所有优点。

这种办法同样有效：

• 对于无法/不会因任何原因被分割成微服务的单片代码基/产品
• 将代码基/产品划分为微服务，即使是出于独立部署功能以外的其他原因--它们不想处理服务间依赖关系管理，而更愿意坚持单块部署(它们仍然共享同一个开发分支)。

注意:实际的SCM存储库是不相关的，它可以是作为一个单独管理的repos的任意组合，分支一词仅表示存在于该组合中的任何物理/实际回购分支的公共逻辑表示。