SVN Web开发工作流程

Question

我已经阅读了许多关于此问题的SO（Stack Overflow）问题，但是我实际上找不到适合我们情况的好建议。我继承了这个工作流程，并且正在尝试使其更好。

我们的设置

• PHP代码库（特别是Kohana）
• 代码库为大约60个站点提供支持，每个站点都有独特的模板（即60个QA [质量保证]域）
• 每个站点都有不同资产和资源的A记录（即每个域名有8个A记录）
• 3个开发人员
• 3个设计师
• 开发人员在本地开发时拥有生产服务器的VMware映像
• 设计师没有
• 共享物理开发服务器用于QA，提交后更新始终将该服务器保持在主干的当前HEAD处
• 生产服务器，根据所使用的功能而更新到不同版本的混合和匹配版本

我们的工作流程

• 开发人员在本地工作，直到某个功能完成，然后将整个功能提交给主干进行内部QA。
• 设计师仅对CSS / 图像/模板进行小的更改。他们直接提交给主干，对自己的更改进行QA，并在通常情况下立即更新生产服务器上相应的文件。
• 当功能准备好上线时，手动将生产服务器更新为与该功能相关的文件的正确修订号。 有时这很简单，有时则非常复杂（需要大量的svn log调用以查找上游依赖项）。

我们的问题

• 由于三个不同的开发人员正在处理需要不同数量QA的不同功能，我们经常遇到上游依赖性问题。
• 在任何时间点，我们都没有办法以编程方式确定哪些功能已在生产服务器上，哪些功能尚未上线。 svn status -u会显示哪些文件不是最新的，但这通常不是功能的清晰图像。

我所知道的

• 通过建立生产分支，我们可以缓解一些问题。 我们至少可以监控哪些功能已经添加到生产环境中以及何时添加，尽管这并不能解决上游依赖问题。
• 功能分支是一个选择，我们过去尝试过这样做。 由于我们的软件需要每个分支60个QA领域，因此我们会遇到一些流程管理问题。例如，每个特性分支都需要创建480个（60个领域×每个领域8条记录）A记录。
• 开发人员分支也是一种选择，但我们的功能QA时间各不相同。我无法确定之前的功能在我需要提交其他内容之前是否已经完成QA。

上游依赖性示例

• 开发人员A在管理界面和前端都添加了新的幻灯片演示功能。
• 开发人员B在管理界面和前端都添加了新的反馈功能。
• 这两个功能与Location模型/控制器逻辑交织在一起，因此对这些关联文件进行了更改以适应这两个新功能。
• 幻灯片演示功能进入质量保证阶段，但因某些开发疏忽或范围膨胀而被拖延。
• 反馈功能进入质量保证阶段，并且没有问题通过。
• 我们想按时间表推动反馈功能进入生产环境，但我们无法直接进行操作，因为这两个功能都需要更改Location模型/控制器。也就是说，我们不能仅通过 svn update file1 file2 file3 命令来完成。
• 注意： 这只是一个简单的示例，可以通过进行一些反向合并来解决它。通常我们的问题比这个复杂得多。

多站点结构信息

• 我们有许多预定义的结构主题，包括视图，图片，CSS文件，JS文件等。
• 每个站点都分配了一个主题。
• 出于品牌和可扩展性的原因，每个站点都可以使用自定义视图覆盖主题视图或包含其他特定于站点的CSS / JS文件。

我相信肯定有其他人也遇到了类似的问题，希望能从你们这些在互联网上聪明的人那里得到一些见解。如果我说的不够清楚，请随时提问！

- BBonifield

---

我有一个问题，QA代表什么？ - Jim

听起来主要问题是您的软件应该是模块化的，但是您试图在文件层面上实现它，而不是在应用程序层面上。 您应该将此可定制性作为应用程序的显式部分，并通过配置文件进行控制，仅维护一个可以推送到所有服务器的代码库的单个版本。这应该会大大简化事情。 - deceze

@Brad lmao，我正在将这篇帖子转发给我们的QA主管，她认为没有开发人员知道什么是QA。lol。 - Byron Whitlock

@deceze/BBonifield：我也认为这会有所帮助，我的工作场所在高效生产流程方面仍停留在80年代吗？我强迫自己工作了一些长时间，直到基本上拥有了一个单一的代码库和每个项目所需的子类/配置等。只有当一个功能完成并被认为是有价值的时候，我才将其添加到我们的代码库中。我想这取决于做这件事所涉及的工作量，是否对现有代码来说是可能的。 - danjah

@BBonifield 当我看到你在生产服务器上单独更新文件并混合版本时，我就会感到非常担忧。也就是说，如果我对所有文件进行一次天真的svn up操作，我可能会完全搞砸你的整个生产服务器。这是不好的。你应该随时能够从你的代码库中部署特定目录的最新版本并且使其正常工作。任何比这更复杂的东西都会导致过早的脱发（正如你所看到的）。我猜你的问题是如何实现这种状态？ - deceze

Answer 1

好的，我有几个想法：

对于这种工作流程，你最好使用具有流模型的SCM，例如Accurev或ClearCase。在流模型中，工作从每个开发人员的流到集成流，然后到QA流，然后到发布流（或任何最佳工作流）。只有准备推进到下一个阶段的工作才会被移动，而集成可以仅与那些工作包进行。

正如deceze所说，您需要更加模块化地拆分事物，但您还需要将其与本地化系统相结合，其中客户特定功能可以覆盖代码的特定部分。我在PHP中实现了一种方式，即实现了一个PHP文件导入包装器，该包装器首先查找PHP文件的客户特定版本，如果不存在，则加载通用版本。

function importModule($module, $clientId){
   if(is_file("${clientRootDir}/${clientId}/${module}.php")) {
      import("${clientRootDir}/${clientId}/${module}.php");
   } else {
      import("${defaultRootDir}/${module}.php");
   }
}

使用这种技术，您可以优雅地覆盖网站工作的部分，仅适用于该客户端，并且为该客户端工作的人在完全不同的文件中工作，因此他们不会相互干扰。我不确定您是否已经这样做了，这就是您所称的“位置模型”。

最后，对于这么多不同的“虚拟网站”进行测试，您将受益匪浅，因为添加自动化单元测试（如PHPUnit）与持续集成相结合，可以在软件升级到集成阶段时自动启动测试。

- dj_segfault

Answer 2

你的工作流程可以得到改善，以下是我的建议清单：

• 开始定期使用SVN分支和发布构建/部署。
• 确定您的部署周期应该多长时间，留出时间进行QA。例如，如果您每个月发布一个版本，则需要3周的开发时间和1周的QA时间。在3周后冻结该版本的开发，除了修复错误之外不再进行其他更改。
• 为您的构建选择一个编号方案，以便有足够的空间进行扩展。
• 利用一个票务系统（ActiveCollab、JIRA、Mantis等），并强制执行任何提交都必须与一个票务相关联的规则。选择一个可以使您的提交自动显示在票务中的系统。
• 如果您要在开始开发之前记录需求，请不要在票务系统中收集您的需求（天哪）。
• 这样做将帮助您确定给定版本中包含哪些功能。因此，请为每个版本制作一些发布说明，其中包含票务号码列表或票务的一般描述。
• 将您的构建编号嵌入到应用程序中，以便您可以跟踪任何给定系统上的部署情况。
• 开始使用自动化测试工具PHPUnit进行单元测试和Selenium进行功能测试，以加快QA速度，并通过减少日常更改引入新错误的可能性来提高Web应用程序的质量/稳定性。
• Hudson和Phing可以帮助您自动化构建和测试，是您的救星。

- LLBBL