SVN Web 开发工作流程答案

【问题标题】：SVN Web Development WorkflowSVN Web 开发工作流程
【发布时间】：2010-11-17 23:06:32
【问题描述】：

我已经阅读了与此问题相关的许多关于 SO 的问题，但我真的找不到任何适合我们情况的好建议。我继承了这个工作流程，我正在努力让它变得更好。

我们的设置

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

我们的工作流程

开发人员在本地工作，直到完成给定功能，然后将整个功能提交到主干以进行内部 QA。
设计人员仅对 CSS/图像/模板进行小幅更改。他们直接提交到主干，QA 自己的更改，并更新生产服务器上的相应文件，一般来说，在他们的 QA 之后立即进行。
当功能准备好上线时，生产服务器会手动更新到与该功能相关的每个文件的正确修订号。有时这很简单，有时却很麻烦（很多 svn log 调用以查找上游依赖项）。

我们的问题

三个不同的开发人员在开发不同的功能，需要不同数量的 QA，我们发现自己经常遇到上游依赖问题。
在任何给定时间，我们都无法以编程方式确定哪些功能在生产服务器上，哪些不在。 svn status -u 会告诉我们哪些文件不是最新的，但这通常不是一个清晰的功能图。

我所知道的

我们的一些问题可以通过生产分支得到缓解。我们至少可以监控哪些功能被添加到生产环境中以及何时添加，尽管这并不能解决上游依赖问题。
功能分支是一种选择，我们过去曾尝试过。由于我们的软件每个分支需要 60 个 QA 域，我们在那里遇到了流程管理问题。例如，为每个功能分支创建 480 个（60 个域 x 每个域 8 条记录）A 记录。
开发人员分支也是一种选择，但我们的功能 QA 时间会有所不同。在我需要提交其他内容之前，我不能肯定地说之前的功能会超出 QA 范围。

上游依赖示例

开发人员 A 在管理和前端都添加了新的幻灯片功能。
开发者 B 在管理和前端都添加了新的反馈功能。
这两个功能都与位置模型/控制器逻辑交织在一起，因此对这些关联文件进行了更改以考虑这两个新功能。
幻灯片功能进入 QA，但由于一些开发监督或范围蔓延而受阻。
反馈功能进入 QA 并顺利通过。
我们希望按照时间线将反馈功能推送到生产环境，但我们不能直接这样做，因为这两个功能都需要更改位置模型/控制器。也就是说，我们不能只做一个svn update file1 file2 file3。
注意： 这是一个简单的例子，可以通过反向合并来解决。通常我们的问题比这复杂。

多站点结构信息

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

我敢肯定还有其他一些人也遇到过类似的问题，我希望从互联网上的聪明人那里得到一些见解。如果我说的话看起来很清楚，请随时提出问题！

【问题讨论】：

问个问题，QA 代表什么？
听起来主要问题是您的软件应该是模块化的，但您试图在文件层而不是应用程序层实现这一点。您应该使这种可定制性成为应用程序的显式部分，可通过配置文件进行控制，并且只维护可以一次推送到所有服务器的单一版本的代码库。这应该会大大简化事情。
@Brad lmao，我将这篇文章转发给我们的 QA 负责人，她认为没有一个开发人员知道 QA 是什么。大声笑。
@deceze/BBonifield：我也认为这会有所帮助，当谈到高效的生产工作流程时，我的工作场所仍然生活在...... 80 年代（？）。我强迫自己工作了很长时间，直到每个项目基本上都有一个代码库和子类/配置/等。只有当一个功能完成并被认为值得时，我才会将它添加到我们的代码库中。我想这取决于执行此操作所涉及的工作量，如果它甚至是现有代码的可能性。
@BBonifield 当我看到您正在对生产服务器上的单个文件进行 svn 更新、混合版本时，我就会升起一个大红旗。也就是说，我可以通过在所有文件上发出一个简单的svn up 来完全搞砸你的整个生产服务器。这简直太糟糕了。您应该能够在任何时候从您的存储库中部署特定目录的最新版本并使其正常工作。任何比这更复杂的事情都会导致过早脱发（如您所见）。我猜你的问题是如何达到这个状态？

标签： php svn workflow

【解决方案1】：

您的工作流程可以改进，以下是我的建议列表：

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

【讨论】：

【解决方案2】：

好的，有几个想法：

对于这种工作流程，使用具有流模型（如 Accurev 或 ClearCase）的 SCM 会做得更好。在流模型中，工作从每个开发人员的流流到集成流，然后是 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");
   }
}

使用该技术，您可以优雅地覆盖网站仅针对该客户的部分工作方式，并且为该客户开发该功能的人员在一个完全不同的文件中工作，因此他们不会相互碰撞。我不确定您是否已经这样做了，这就是您所说的“位置模型”

最后，如果要测试这么多不同的“虚拟网站”，您将受益于添加自动化单元测试（a la PHPUnit）并结合持续集成，以便在软件进入集成阶段时自动启动测试。

【讨论】：