持续集成-突破性变化

这是许多发展抽象中众所周知的问题。在微服务和库开发环境中,通常都会在一定程度上提供向后兼容性。它为依赖它的其他服务提供了更新的时间,直到旧功能被删除。如果这不是一个选择,因为它有许多缺点,需要很多规划和文化,使之正确,我建议永远不要打破主人。

所以我的答案是 三

我选择的原因是:

• 建议 我不会用正统版的软件,如果这个版本坏了,软件就坏了。有些开发工作流甚至不允许开发人员在通过所有测试和代码评审后提交到主控服务器,其中只有CI完成合并。它有管理CI、代码评审的成本,并且需要团队中定义良好的文化。
• 建议 我认为这意味着开发人员2在他的计算机中放置了一个“staging”就绪的代码,等待依赖项就绪。他有空间在做其他工作时做错事或把事情搞砸。我总是试图在一天结束时提交任何有意义或未完成的代码,以避免任何损失。通常在特征分支中。它救了我几次。
• 建议 三
• 建议 4个 这有点像向后兼容的情况,但如果这个系统不像库、框架或微服务这样的方法,听起来就不对。我还假设此功能没有计划的弃用寿命,因为它看起来只有一个依赖于它的模块。

我不确定它是否适用于你的案子,但是 git submodules