使用持续集成代表了（几乎）强制性的软件项目敏捷性要求。如果没有CI，就不会有连续的交付/部署。

但是CI可能会面临可扩展性挑战，请参阅如何为大型项目/团队进行持续集成扩展？。

拆分在多个较小的预集成分支上进行工作将可以使这些分支上的工作变得敏捷，但随后需要处理这些预集成分支的合并。这些将是大规模的，不可预测的合并，相当难以计划并整合到敏捷框架中。在实际执行合并之前，人们还无法真正确定是否需要2个小时，2天或2个完整的sprint。

那么，敏捷方法论如何仍可以应用于庞大的整体软件拥有100/1000开发人员的项目？

评论

这个问题混合了两个大主题，一个是大型团队的敏捷性，另一个是许多大型项目的Ci / CD。如果您可以将此问题至少分成两个问题，而又不将另一个问题弄混，那将是真正有益的。 “分支”不是敏捷，人员和团队以及工作项是敏捷的作用范围。
但是，恕我直言，这些主题非常相关。将它们放在一起看，作为一个系统（这是现实，如果您考虑一下的话）可以提供优化的机会，而如果单独查看它们，这是无法看到的。
每天需要2个小时，每天进行部署，自动测试或手动合并？
@kenorb：整个过程-我的意思是，直到完成并提交SCM合并，成功构建和测试构件以及部署实际上证明整个过程是可以接受的（或完成了），您才能真正声明分支合并成功。 br />

#1 楼

好吧，您将无法将敏捷方法应用于大型团队。通常的原则之一是在披萨团队中工作（少于10人，可以一起共享一个大披萨作为晚餐），因为敏捷流程所倡导的缺乏形式主义使得它几乎不适用于大型团队，信息会分散并且一些

因此，在考虑CI系统之前，您必须检查所构建软件的组织。
这主要需要在较小的独立部分，它可以是单独的软件（并且您将沿用微服务），也可以只是软件中的体系结构设计，其中将类/对象/库分配给一个小型团队。该团队必须记录其服务输入和输出（服务合同/服务方向）。

完成此操作后，您可以将每个独立部分的职责分配给一个较小的团队，该团队可以应用敏捷的过程。
这可能会解决CI / CD问题，拆分代码库将允许每个团队按照自己的步调，只要接口的版本正确且输入/输出固定为某种类型即可。调用，您可以使产品的某些部分继续发展，而另一些部分保持先前的行为。

主要缺点是来自每个部分的服务合同必须在使用的版本之间兼容，这需要依赖系统在删除未使用的API版本之前要知道哪个部分使用哪个版本。这带来了需要做出重大改变的问题，通常需要在生产者和消费者之间进行仔细的横向计划。

评论

对于具有遗留单片代码的嵌入式系统，微服务很少是实际的解决方案。而且，总的来说，微服务为系统的复杂性增加了一个全新的维度，它们实际上并不像通常宣传的那样容易。但是我离题了-问题特别是关于整体式sw;）

–丹·科尼莱斯库（Dan Cornilescu）
17年3月3日在14:09
然后，第二种选择是通过“库”拆分（很难说出我们在谈论什么代码库，很难知道），对于大型库来说，这是一种将责任划分到部件上的可能性，而这些部件的重叠可能会更少（一旦完成） ，尽可能拆分库本身）可能是解决此问题的一种方法。

–滕西拜
17年3月3日在14:13
肯定有大型团队如何应用敏捷方法的示例。 SAFe是一个示例，LeSS也是如此。

– Evgeny Zislis
17 Mar 3 '17 at 17:54
那些方法成功实施的真实示例？我只记得失败会回到V周期或长时间迭代，最终是一种混合组织，而不是真正的敏捷

–滕西拜
17 Mar 3 '17 at 18:02

#2 楼

我们从由数百名开发人员工作的大型，整体式后端应用程序发展为基于docker的微服务，并使用ansible和类似的DevOps fluff进行部署。以下是有关此过程的一些说明：


确定单片应用程序内部的域边界。确保边界之间的调用尽可能少地发生（所谓的调用，指的是进程内调用或数据库访问）。
将开发人员分成多个团队，并为每个团队分配一个域的一部分。 （有可能一个域也可以在多个团队中工作）
指定仍然发生跨边界调用，并在其周围定义一个API。跨域调用时，请确保仅使用此中间库。
围绕这些中间库进行适当的测试，以检查它们是否正常工作。
根据这些域拆分代码。

现在，您的每个团队都应该规模较小，并且在编写自己的代码时不必担心其他团队。您放入这些中间库中的测试应涵盖外部调用者的回归，而内部代码则由您负责。显然，如果中间库需要更改，或者如果您的测试告诉您您不再遵守API规范（这种规范可能偶尔发生），那么您需要开始使用这些API与其他团队讨论。

一旦您满意，您可以尝试将这些中间库替换为HTTP API调用，而不是进程内调用。完成此操作后，您实际上可以将大型应用程序拆分为较小的实际部分（它们可能仍然不是“微”服务，而是更小，更易于管理）。此外，它们至少将属于一个特定域，并且具有清晰，定义明确的API，其他API（包括大多不包含旧有大应用程序的新微服务）可以用来获取其数据。

#3 楼

是的，将较大的团队分成较小的，敏捷的子团队显然是必要的。但是，要在较大的团队级别上同时保持整体表现还远远不够。

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

克服了这些障碍，子团队可以真正充分利用敏捷技术，因为它们会自动全部投入相同的页面，并受益于CI方法的所有优势。

这种方法也同样有效：



对于无法/无法获得的整体代码库/产品无论出于何种原因，都无法将其拆分为微服务
，即使出于独立部署功能之外的原因，代码库/产品也拆分为微服务-不想处理服务间依赖关系管理，并且更愿意坚持单一部署（它们仍然共享同一个开发分支）

注意：实际的SCM存储库无关紧要，它可以是由单个仓库一起管理的仓库的任何组合，术语“分支”仅表示该组合中存在的任何物理/实际回购分支的通用逻辑表示。

#4 楼

我一直在与100多个开发人员一起完成几个敏捷项目，而没有任何问题，因此，以我的个人经验，为了处理如此大的工作流，这里有一些建议：



绝对应该拆分团队（每人最多〜12人）。

请确保您在每个团队中都有具有正确技能的正确人员，因此他们是独立的（跨职能的）团队）。 DevOps不必是开发团队的一部分。

每个团队都应该在自己的组件/模块上工作，因此他们的工作不会与其他团队发生冲突。
一旦功能/组件或错误已在单独的分支中完成和测试，开发人员应负责发送和维护有效的可合并Pull Request，以供其他团队成员批准。
经常提交和从master分支中进行提取将避免任何有关代码冲突的惊喜。
应在CI中自动测试每个Pull Request，并在批准后将其合并（开发或主分支）。
应在每个合并并在开发环境中进行测试的Pull Request上部署到开发分支通过自动测试和手动进行，因此只有稳定的代码才能向上游进行。

总而言之，为了避免在合并复杂分支上花费太多时间，要点是引入了Pull Request，因此每个请求者都应负责为了自己的能力可合并n代码和其他开发人员负责检查更改，因此在这种情况下，不可能发生任何不可预测的分支或冲突。

所以是的，敏捷方法可以扩展到大规模项目。