持续集成-重大变化

Question

假设Developer1在Module1上工作，Developer2在Module2上工作，而Module1取决于Module2。 Developer2今天完成了Module2的工作，但是如果将其更改提交给CI服务器，他的更改将中断Module1。但是，Developer1需要花几天的时间才能使Module1适应Module2中的更改。

就持续集成而言，Developer2应该做什么？

1. 完成他的日常工作并破坏版本吗？
2. 等待Developer1在Module1上完成工作然后一起提交吗？ （这是否会反对CI？）
3. 提交到功能分支（如果构建失败，可以这样做），而不是Master分支，并且当Developer1完成在功能分支上的工作时，将其合并到Master分支中。 （这是否会反对CI？）
4. 编写另一个类，而不要修改现有的类。当Developer1完成工作后，他将切换到新课程。 （有点像SOLID的Open / Closed原理）
5. 还是其他选择？

Answer 1

这是许多开发抽象中的众所周知的问题。在微服务和库开发环境中，通常总是在某种程度上提供向后兼容性。它给其他依赖它的服务更新时间，直到删除旧功能为止。如果这不是一个选择，因为它有很多缺点，并且需要很多计划和文化才能使其正确，我建议您永远不要破坏大师。

所以我的回答是 3 -在这种情况下，功能分支是一个不错的选择，因为它适用于几乎所有工作流程，并且很容易与任何团队合作。

我选择的原因是：

• 建议 1 我不会使用标准版本的软件作为主版本，如果此版本已损坏，则软件已损坏。某些开发工作流程甚至不允许开发人员提交给主控方，在该主控方通过所有测试和代码审查后仅由CI进行合并。这需要管理CI，进行代码审查并需要在团队中建立良好定义的文化。
• 建议 2 我认为这意味着开发人员2的计算机中有一个“暂存”就绪代码，正等待相关性就绪。他在处理其他任务时有做错事或弄乱事情的余地。我总是试图在一天结束时提交有意义或未完成的任何代码，以免造成任何损失。通常在功能分支中。它救了我几次。
• 建议 3 是此列表中适合我的一项。它可以节省开发人员的2项工作，并且不会破坏母版，并且可供团队使用。关于中断构建，在某些CI系统中，如果已知会破坏构建，则提交中的标志可以避免构建。
• 建议 4 这有点像向后兼容的情况，但假设此系统看起来不像这种方法的情况（如库，框架或微服务），这听起来并不正确。我还假定此功能没有计划的弃用期限，因为看起来只有一个模块取决于它。

我不确定它是否适用于您的情况，但是使用git submodules也可以解决此问题，因为每个模块都有自己的存储库。每个依赖项都是指向固定在特定版本上的另一个模块的存储库的链接。这样可以避免因破坏依赖关系而导致的问题，而需要手动设置和更新版本。随着模块和依赖项数量的增加，这可能会非常费力。