我刚刚加入的公司有一个产品系统，它们共享大部分代码库（通过Visual SourceSafe中的共享链接）。该系统中约有25种产品类型以及PC接口。
产品使用大部分未记录的专有协议联网。从历史上看，维护这种混乱的方法是要求所有固件和软件作为包发布。当然，由于需要进行回归测试，这会导致发布计划的显着延迟。
还有其他人有成功处理此类问题的方法吗？我们真的被管理层打败了（老实说，我不能因为这种感觉而错过了它们。）
我的第一个想法是尝试以某种方式将设备版本彼此分开。也许将共享功能拉入版本化的库中。然后只更新使用已更改的库的设备。但是，我看到版本不匹配的问题。
这是一个组织问题。我理解如何通过测试和流程保持纸牌的存在，但我相信更好地组织代码库可以产生很多好的结果。
我很欣赏这个建议。
答案 0 :(得分：-1)
由于需要进行回归测试，因此会严重延迟发布时间表。
这就是为什么人们会做“daily build”。
每日构建通常包括一组测试，有时称为a 烟雾测试（如有烟有火的地方）。这些测试 包括在内以帮助确定可能被破坏的内容 更新包含在最新版本中。关键的一点 过程是在项目进展时包括新的和修订的测试。
当组织 - 作为一个整体 - 必须保持日常构建工作时，人们就会改变他们的责任，观点，偏见，投诉和行动，以保持每日构建的运行。
每日站立会议专注于可能破坏构建的事情。
个别开发人员必须更仔细地重构他们的代码，以避免破坏构建。
打破构建成为即时，即时的指示，表明某些内容不同步。即时。没有延迟。如果我今天打破构建，明天早上每个人都会知道。没有几天浪费假设（或希望）事情仍然有效。我们可以立即回滚更改，或应用更改以继续前进。