有关管理发布的依赖项的提示？

Question

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

我们的团队通常一次完成4个或5个项目.我们试图每2-4周将许多变化归结为大型推出.

我的问题是跟踪转发的所有依赖关系.例:

网站A无法上线,直到我们推出了类库B的分支X,依次针对类库C的Trunk构建,它需要配置更新Y和Z以及数据库更新D,这需要迁移脚本E ...

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

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

• 白板列出尚未上线的功能
• 在计划推出时依靠我们的记忆和直觉,直到我们确信我们已经想到了一切......
• 在我们的临时环境中干涸.这是一个很好的指示,但我们经常不确定Staging是否与Live实现100%同步 - 这是我希望解决的问题的一部分.
• 在推出当天有一些翼展.

到目前为止这么好,减去几个近距离的电话.但是随着我们系统的发展,我想要一个更科学的发布管理系统,允许更多的灵活性,比如能够自己推出单个更改或错误修复,安全知道它不会破坏其他任何东西.

我猜测最好的解决方案涉及某种版本编号系统,也许使用项目管理工具.我们是一个初创企业,所以我们并不热衷于坚持严格的流程,但我们很高兴开始,只要它不会增加额外的开销.

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

Answer 1

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

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

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

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

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

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