Project management 如何管理共享代码的多个产品

我刚刚加入的公司有一个产品系统，它们共享大部分代码库（通过Visual SourceSafe中的共享链接）。该系统中有大约25种产品类型以及一个PC接口

该产品使用大量未记录的专有协议联网。历史上，维护这种混乱的方法是要求所有固件和软件作为一个包发布。当然，由于所需的回归测试，这会导致发布计划的显著延迟

还有谁有成功的方法来处理这类问题吗？我们真的被管理层痛打了一顿（老实说，我不能怪他们有这种感觉）

我的第一个想法是尝试以某种方式将设备版本彼此分离。可能将共享功能拉入已版本化的库中。然后仅更新使用已更改库的设备。但是，我从中看到了版本不匹配的问题

这是一个组织问题。我知道如何通过测试和过程来保持卡片屋的运转，但我相信更好地组织代码库会有很多好的结果

我很感激你的建议

由于所需的回归测试，发布计划出现重大延迟

这就是为什么人们会做一个“

日常构建通常包括一组测试，有时称为 烟度测试（如有烟就有火）。这些测试 用于帮助确定哪些部件可能已被损坏 最新版本中包含的更改。这其中的关键部分 随着项目的进展，该过程将包括新的和修订的测试

当组织——作为一个整体——必须保持每日构建工作时，人们就会改变他们的职责、观点、偏见、抱怨和行动，以保持每日构建的运行

每天的站立会议都会关注可能破坏构建的事情

个别开发人员必须更仔细地重构代码，以避免破坏构建

---

破坏构建成为某种不同步的即时指示器。立即的。不要耽搁。如果我今天破坏了结构，明天早上每个人都会知道的。假设（或希望）事情仍然有效，没有浪费任何时间。我们可以立即回滚更改，或应用更改以继续前进。

我们可以这样做。这让它一直在编译。我想你也指的是每日构建之后的自动测试。我想这样做，但我们目前还没有基础设施。这不是个人电脑软件，所以需要做大量的自动化测试。“只是目前还没有基础设施”。那没有关系。你问我该怎么办。你并不孤单。其他每个有这个问题的人都通过运行单元测试的每日构建来解决它。这几乎是标准的解决方案。如果您没有基础设施，这不会改变解决方案，是吗？成本（金钱、时间）总是相关的。不，它不会将其作为选项删除，但它确实有助于分配优先级。如果听起来我不同意，我很抱歉。我完全同意，但是需要考虑所有的选择。你说的话根本不能解决所有问题。@caveman：“你说的话根本不能解决所有问题”？为什么不呢？这是标准溶液。它解决不了什么？这里也有组织问题。烟雾测试不是灵丹妙药。