我们的系统包含许多.NET网站，类库和MSSQL数据库。我们使用SVN进行源代码控制，使用TeamCity自动构建到测试服务器。
我们的团队通常一次只处理4个或5个项目。我们试图每2-4周将许多变化归结为大型推出。
我的问题是跟踪推出的所有依赖项。示例：
网站A无法上线，直到我们推出了类库B的分支X，它依次针对类库C的Trunk构建，它需要配置更新Y和Z以及数据库更新D，这需要迁移脚本E. ..
它变得更加复杂 - 比如确保每个开发人员的项目实际上与其他项目兼容并且正在构建相同的版本。是的，这是一个管理问题，也是一个技术问题。
目前我们的非最佳解决方案是：
到目前为止这么好，减去几个近距离的电话。但随着我们系统的发展，我希望有一个更科学的发布管理系统，允许更多的灵活性，比如能够自己推出单个更改或错误修复，安全知道它不会破坏其他任何东西。< / p>
我猜测最好的解决方案涉及某种版本编号系统，并且可能使用项目管理工具。我们是一个初创公司，所以我们并不热衷于虔诚地坚持严格的流程，但我们很高兴开始，只要它不会增加更多的开销而不是它的价值。
我很想听听解决这个问题的其他团队的建议。
答案 0 :(得分：1)
听起来你已经有了一个Continuos Integration Server，但是没有正确使用它。部分问题在于您不知道哪些更改最终会在发布中发生，哪些不会发生。
我假设您的所有项目都是包含项目的一部分，其中存在源代码控制存储库。作为第一个衡量标准，您应该尝试将开发中的代码与分支中的稳定/待发布代码分开。设置Teamcity以定期完整构建稳定分支。如果一组更改已准备好发布，则更改的创建者应负责将它们与所有依赖项一起合并到稳定分支中。 CI将告诉您一切是否顺利。 CI的想法是你“随时准备发布”。
您提到您的团队正在开展多个项目并且他们之间存在某些相互依赖关系。这让我有点怀疑：
根据我的经验，管理二进制级别的依赖项总是更容易（只需升级项目中的库）。另一方面，我从未遇到过不相关的项目依赖于同一个dll的情况（这本身就是一个应用程序，而不仅仅是一个实用程序库或其他东西）。在这种情况下，更容易管理源级别的依赖项。
最后，一个随机的想法：如果您使用分布式版本控制系统（例如git或mercurial），将所有代码放在同一个存储库中将非常容易。每个项目都可以拥有自己的分支，该分支通过主分支（前向集成）的最新更改进行定期更新。 更改完成后，项目分支将合并回主分支（反向集成）。 Microsoft的Windows团队提出了这个工作流程。