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

Question

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

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

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

Website A cannot go live until we've rolled out Branch X of Class library B, built in turn against the Trunk of Class library C, which needs Config Updates Y and Z and Database Update D, which needs Migration Script E...

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

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

尚未上线的白板列表功能

在计划推出时依靠我们的内存和直觉，直到我们非常确定我们已经考虑了所有事情...

在我们的 Staging 环境中试运行。这是一个很好的迹象，但我们通常不确定 Staging 是否 100% 与 Live 同步——这是我希望解决的问题的一部分。

在推出当天进行一定数量的翼展。

到目前为止一切顺利，减去了一些接近的电话。但是随着我们系统的发展，我想要一个更科学的发布管理系统，允许更大的灵活性，比如能够自己推出单个更改或错误修复，因为知道它不会破坏其他任何东西，这是安全的。

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

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

Answer 1

听起来您已经有一个 Continuos Integration Server，但没有正确使用它。部分问题是您不知道哪些更改会在发布中结束，哪些不会。

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

你提到你的团队有几个项目一直在努力，它们有一定的相互依存关系。这让我有点怀疑:

如果项目是相互依存的，为什么它们是分开的？即使它们以不同的速度进化，它们真的需要分开吗？

因此，您是否为每个项目拥有不同的存储库？这将使发布变得非常困难。

可以在二进制级别管理依赖项吗？或者是否存在编译时依赖性？

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

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