我们的团队通常一次完成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是否与Live实现100％同步 – 这是我希望解决的问题的一部分.
>在推出当天有一些翼展.
到目前为止这么好,减去几个近距离的电话.但是随着我们系统的发展,我想要一个更科学的发布管理系统,允许更多的灵活性,比如能够自己推出单个更改或错误修复,安全知道它不会破坏其他任何东西.
我猜测最好的解决方案涉及某种版本编号系统,也许使用项目管理工具.我们是一个初创企业,所以我们并不热衷于坚持严格的流程,但我们很高兴开始,只要它不会增加额外的开销.
我很想听听解决这个问题的其他团队的建议.
听起来你已经有了Continuos Integration Server,但是没有正确使用它.部分问题是您不知道哪些更改将在发布中结束,哪些不会发布.我假设您的所有项目都是包含项目的一部分,其中存在源代码控制存储库.作为第一个衡量标准,您应该尝试将开发中的代码与分支中的稳定/待发布代码分开.设置Teamcity以定期完整构建稳定分支.如果一组更改已准备好发布,则更改的创建者应负责将它们与所有依赖项一起合并到稳定分支中. CI将告诉您一切是否顺利. CI的想法是你“随时准备发布”.
您提到您的团队正在开展多个项目并且他们有一定的相互依赖性.这让我有点怀疑：
>如果项目是相互依存的,为什么它们是分开的？即使它们以不同的速度发展,它们真的需要分开吗？
>因此,每个项目都有不同的存储库吗？这将使释放变得非常困难.
>可以在二进制级别上管理依赖项吗？还是编译时依赖？
根据我的经验,管理二进制级别的依赖项总是更容易(只需升级项目中的库).另一方面,我从未遇到过不相关的项目依赖于同一个dll的情况(这本身就是一个应用程序,而不仅仅是一个实用程序库或其他东西).在这种情况下,更容易管理源级别的依赖项.
最后,一个随机的想法：如果你使用分布式版本控制系统(例如git或mercurial),那么在同一个存储库中拥有所有代码将非常容易.每个项目都可以拥有自己的分支,该分支通过主分支(前向集成)的最新更改进行定期更新.
更改完成后,项目分支将合并回主分支(反向集成). Microsoft的Windows团队提出了这个工作流程.