关于管理版本依赖关系的提示？

Question

我们的系统包含许多.NET 网站、类库和 MSSQL 数据库。我们使用 SVN 进行源代码控制，并使用 TeamCity 自动构建测试服务器。

我们的团队通常同时处理 4 或 5 个项目。我们尝试将许多更改集中到每 2-4 周一次的大规模部署中。

我的问题是跟踪部署的所有依赖项。例子：

在我们推出类库 B 的分支 X 之前，网站 A 无法上线，该分支 X 是针对类库 C 的主干构建的，需要配置更新 Y 和 Z 以及数据库更新 D，需要迁移脚本 E。 ..

...变得更加复杂 - 比如确保每个开发人员的项目实际上与其他开发人员兼容并且针对相同版本进行构建。是的，这既是一个技术问题，也是一个管理问题。

目前我们的非最佳解决方案是：

• 在白板上列出尚未上线的功能，
• 在计划推出时依靠我们的记忆和直觉，直到我们非常确定我们已经想到了所有内容......
• 在我们的暂存环境中进行一次演练。这是一个很好的迹象，但我们经常不确定Staging 是否与Live 100% 同步——这也是我希望解决的问题的一部分。
• 在推出当天进行一些即兴发挥。

到目前为止一切都很好，除了一些险些发生的事情。但随着我们系统的发展，我想要一个更科学的发布管理系统，允许更大的灵活性，比如能够自行推出单个更改或错误修复，并且知道它不会破坏其他任何东西。

我猜最好的解决方案涉及某种版本编号系统，也许还需要使用项目管理工具。我们是一家初创公司，所以我们不太热衷于严格遵守严格的流程，但我们很乐意开始，只要它不会增加超过其价值的开销。

我很想听听解决了这个问题的其他团队的建议。

Answer 1

听起来您已经有了一个持续集成服务器，但没有正确使用它。部分问题是您不知道哪些更改最终会出现在版本中，哪些不会。

我假设您的所有项目都是一个包含项目的一部分，该项目存在源代码控制存储库。作为第一个措施，您应该尝试将分支中正在开发的代码与稳定/即将发布的代码分开。设置 Teamcity 以定期完整构建稳定分支。如果一组更改已准备好发布，则更改的创建者应负责将它们与所有依赖项一起合并到稳定分支中。 CI 会告诉您一切是否顺利。 CI 的理念是“永远准备好发布”。

您提到您的团队正在持续开展多个项目，并且它们具有一定的相互依赖性。这让我有点怀疑：

• 如果项目是相互依赖的，为什么它们是分开的？即使它们以不同的速度进化，它们真的需要分开吗？
• 因此，您是否为每个项目都有不同的存储库？这将使释放变得非常困难。
• 可以在二进制级别上管理依赖关系吗？或者是否存在编译时依赖性？

根据我的经验，管理二进制级别的依赖关系总是更容易（只需升级项目中的库）。另一方面，我从来没有遇到过不相关的项目依赖于同一个 dll 的情况（它本身就是一个应用程序，而不仅仅是一个实用程序库或其他东西）。在这种情况下，在源级别管理依赖关系会更容易。

最后，一个随机的想法：如果您使用分布式版本控制系统（例如 git 或 Mercurial），那么将所有代码放在同一个存储库中将非常容易。每个项目都可以有自己的分支，该分支定期更新主分支的最新更改（前向集成）。
更改完成后，项目分支将合并回主分支（反向集成）。 Microsoft 的 Windows 团队提出了这个工作流程。