我已经阅读了SO上与此问题相关的许多问题，但是我找不到适合我们情况的好建议。我继承了此工作流程，并试图使其变得更好。
我们的设置
PHP代码库(尤其是Kohana)代码库支持约60个站点，每个站点都有唯一的模板(即也有60个QA [Quality Assurance]域)每个站点都有针对不同 Assets 和资源的A记录(即每个域8条A记录) 3开发人员 3位设计师开发人员具有用于本地开发的生产服务器的VMware镜像设计人员不要用于质量检查的共享物理开发服务器，提交后的更新使该服务器始终保持在主干的当前HEAD上生产服务器，已根据实时的功能更新为不同版本的混合搭配
我们的工作流程开发人员在本地工作，直到完成给定功能，然后将整个功能提交到主干进行内部质量检查。 设计人员仅对CSS/图像/模板进行了少量更改。通常，他们会在进行质量检查后立即直接对中继进行提交，对自己的更改进行质量检查并更新生产服务器上的相应文件。 当准备好启用功能时，将生产服务器手动更新为与该功能相关的每个文件的正确修订号。有时这很简单，有时却很繁琐(很多svn log调用来查找上游依赖项)。 我们的问题由三个不同的开发人员从事需要不同数量QA的不同功能的研究，我们发现自己经常遇到上游依赖性问题。 在任何给定时间，我们都无法以编程方式确定生产服务器上有哪些功能，哪些没有。 svn status -u将向我们显示哪些文件不是最新的，但这通常不是所有功能的清晰图片。 我知道的通过创建生产分支可以缓解我们的一些问题。我们至少可以监视将哪些功能添加到生产中以及何时添加，尽管这不能解决上游依赖性问题。 功能分支是一个选项，我们过去曾尝试过。由于我们的软件每个分支都需要60个QA域，因此我们在其中遇到了流程管理问题。例如，为每个功能分支创建480个(60个域x每个域8个记录)A记录。 开发人员分支也是一个选项，但是我们的功能质量检查时间有所不同。我不能肯定地说，在我需要提交其他内容之前，先前的功能将无法进行质量检查。 上游依赖性示例开发人员A在管理员和前端中都添加了新的幻灯片放映功能。 开发人员B在管理员和前端中都添加了新的反馈功能。 这两个功能都与位置模型/ Controller 逻辑交织在一起，因此对那些关联文件进行了更改以说明这两个新功能。 幻灯片放映功能已进入质量检查，但由于某些开发监督或范围爬升而受阻。 反馈功能可以进入质量检查并通过，并且没有任何问题。 我们想遵循时间轴并将反馈功能推向生产阶段，但是我们不能直接做到这一点，因为这两个功能都需要更改“位置”模型/ Controller 。也就是说，我们不能只做svn update file1 file2 file3。 注意:这是一个简单的示例，可以通过进行一些反向合并来解决。通常，我们的问题比这复杂。 多站点结构信息我们有许多预定义的结构主题，包括 View ，图像，CSS文件，JS文件等。每个站点都分配有一个主题。 出于品牌和可扩展性的原因，每个站点都可以使用自定义 View 覆盖主题 View ，或者包括其他特定于站点的CSS/JS文件。 我敢肯定，还有其他一些人也在为类似的问题而苦苦挣扎，我希望能从互联网上聪明的人们那里获得一些见识。如果我说的话似乎很泥泞，请随时提出问题!
您的工作流程可以改善，这是我的建议 list :
开始使用SVN分支，并定期发布构建/部署。 弄清楚您的部署周期应该多长时间，从而留出时间进行质量检查。因此，例如，如果您每月要发布一个构建，则需要进行3周的开发和1周的质量检查。除错误修复外，在3周后冻结该构建的开发。 决定您的构建的编号方案，以便为腾出空间
使用票务系统(ActiveCollab，JIRA，Mantis等)并强制执行任何提交都必须与票证关联的规则。选择一个可以使提交自动显示在故障单中的位置。 如果要在开始开发之前开始记录需求，请不要在售票系统中收集需求(出于上帝的考虑)这样做将帮助您确定给定版本中的功能。因此，请使用每个票证的票证编号列表或票证的一般说明来制作某种发行说明。 将内部版本号嵌入到应用程序中，以便您可以跟踪任何给定系统上的部署。 开始使用自动化的测试工具PHPUnit(用于单元测试)和Selenium(用于功能测试)，以通过降低日常更改引入新错误的可能性来加快质量检查并提高Web应用程序的质量/稳定性。 Hudson和Phing可以成为使构建自动化和测试自动化的救生员。