我有这样的问题:</p>
当客户要求我们系统的新功能时,我们将所有更改的文件打补丁并发送给与客户合作并进行发布的同事。
但是,并不是每个补丁都是按顺序发布的。所以,补丁 A 有可能依赖于补丁 B,但补丁 B 是在补丁 A 之前发布的。
由于同事不熟悉编程所以他无法弄清楚原因。我必须花时间看看有什么问题。
当等待发布的补丁数量越来越多时,发布补丁对我们来说似乎是一场噩梦。
有没有这样的依赖分析工具?所以我们可以看到补丁的依赖关系,可以减少找出依赖关系的时间。
多谢。
我有这样的问题:</p>
当客户要求我们系统的新功能时,我们将所有更改的文件打补丁并发送给与客户合作并进行发布的同事。
但是,并不是每个补丁都是按顺序发布的。所以,补丁 A 有可能依赖于补丁 B,但补丁 B 是在补丁 A 之前发布的。
由于同事不熟悉编程所以他无法弄清楚原因。我必须花时间看看有什么问题。
当等待发布的补丁数量越来越多时,发布补丁对我们来说似乎是一场噩梦。
有没有这样的依赖分析工具?所以我们可以看到补丁的依赖关系,可以减少找出依赖关系的时间。
多谢。
您可以使用任何依赖管理系统(如 Maven)、用于生产就绪组件(如 Nexus)的内部工件存储库和用于热修复的发布分支(如果您必须以近乎实时的方式发布更新)来完成此操作。
使用这种方法,您可以获得:
简而言之:划分开发和生产版本,您可以保护自己构建一个依赖关系破坏的生产包。
处理这些情况的正确方法是使用配置管理程序。
例如,一个简单的涉及 CVS/SVN 和修订 A 和修订 B 之间的变更日志。
更改日志中的每个文件都将组成补丁。
一个更复杂的程序将引入基线和中间版本。