【发布时间】：2013-08-20 17:14:26
【问题描述】：
大家
我想要关于那个场景的建议：
在大型电子商务门户网站工作的 50 人。大约 35 名开发人员、10 名 QA、5 名经理或类似人员。这些开发人员被划分为具有特定角色的团队，例如前端团队、后端团队等……我们在生产环境中每天发布，这些发布的代码包括错误修复和新功能。
每个开发人员都在开发新功能或修复错误，这可能涉及不同的孤岛或影响它们。今天在 TFS，我们致力于 2 个不同的集合和数十个不同的团队项目。尽管如此，所有工作都是由特定团队项目中的工作项组织的。
在这家公司，代码在投入生产之前由 QA 批准，所有代码集成、合并和部署都由一个名为 ALM 的团队负责（这项工作有 4 人全职）
我的问题是关于如何组织这种混乱，将 TFS 视为源代码控制系统。我如何构建我的分支机构战略以支持这种情况以及如何制定支持未来持续交付的分支机构战略？我需要一些线索和一些关于新想法的辩论，以提高我团队的生产力并避免我发布到生产环境的代码中的错误。
谢谢！
【问题讨论】：
-
Branches 是一种解决方案，但通常很混乱。尽可能尝试以可以切换尚未完成的功能的方式创建您的应用程序。或者它们作为插件安装到主应用程序中。在合并和配置方面，这为您提供了更轻松的工作流程。分支通常不是为了提高生产力。这是为了保护彼此免受变化影响，并在后期与早期进行整合。
-
切换功能是很棒的技术工具，但我无法切换错误的更正，对吧？或者，如果我的新功能影响了许多文件，那么这个切换将在我的代码中变得一团糟，对吗？但是，尽管如此，我知道我的解决方案中有很多技术债务，因此切换功能会很痛苦...... :(
标签： architecture projects-and-solutions solution