帮助我改进我的持续部署工作流程

Question

我一直在为PHP项目开发一个大多数自动化continuous deployment周期的工作流程。我想对此工作流程中的可能流程或技术瓶颈提供一些反馈，建议改进，以及如何更好地自动化和增加我的团队的易用性的想法。

---

核心组件：

• Hudson CI服务器
• Git和GitHub
• PHPUnit单元测试
• Selenium RC
• Sauce OnDemand使用Selenium RC
进行自动化，跨浏览器，云测试
• Puppet用于自动化测试服务器部署
• Gerrit用于Git代码审核
{li> Gerrit Trigger Hudson

---

编辑：我已更改了工作流程图，以便将ircmaxwell的贡献考虑在内：删除PHPUnit的{​​{1}}扩展名，并仅将其作为QC阶段;增加QC阶段;在代码审查之后但在合并之前移动UI测试;在QC阶段之后移动合并;合并后移动部署。

此工作流程图描述了该过程。我的问题/想法/顾虑如下。

我的疑虑/想法/问题：

• 使用此系统的整体难度。

• 时间参与。

• 难以使用Selenium RC。

• 难以使用Gerrit。

• 我们稍后会在Puppet个实例上进行部署。如果我们要开始使用Amazon EC2设置Debian个包并现在部署到Puppet个切片，那么Linode上的工作部署是否有可能打破Linode 1}？我们应该从一开始就在EC2上进行构建和部署吗？

• 另一个问题：EC2和EC2。我们也在考虑使用Scalr作为解决方案。为了避免单独使用Puppet的开销并投资Scalr，它是否有意义？我这里有关于成本的次要问题（ha！）; Puppet测试不应该运行 ，Selenium构建实例通常会全天候运行，但对于像分钟构建，支付一小时的EC2使用量似乎有点多。

• 合并时可能存在的流程瓶颈。

• 可以移动“A”吗？

积分：此工作流程的部分内容为inspired by Digg's awesome post on continuous deployment。上面的工作流程图形为inspired by the Android OS Project。

Answer 1

有多少人正在研究它？如果您只有10或20个开发人员，我不确定将这样精心设计的工作流程放到位。如果你管理500，那肯定......

我的个人感觉是亲吻。保持简单，愚蠢......你想要一个既有效又更重要的过程：简单。如果它很复杂，要么没有人会做正确的事，要么是在时间部分会滑落之后。如果你把它变得简单，它将成为第二天性，几周之后没有人会质疑这个过程（好吧，无论如何它的语义）......

另一种个人感觉总是在你所有的UNIT测试中运行。这样，您可以跳过流程图中的整个决策树。毕竟，什么更昂贵，几分钟的CPU时间，或大脑周期来理解部分测试传递和大规模测试失败之间的差异。请记住，失败是失败的，并且没有实际的理由认为代码应该显示给有可能使构建失败的审阅者。

现在，Selenium测试通常非常昂贵，所以我可能会同意将这些测试推迟到审核人批准之后。但是你需要考虑那个......

哦，如果我实施这个，我会在那里放一个正式的QC阶段。我希望人类测试人员能够查看正在进行的任何更改。是的，Selenium可以验证你所知道的事情，但只有人才能找到你没想到的事情。将他们的发现反馈到新的Selenium和Integration测试以防止回归......

Answer 2

重要来创建tests extremely fast，即没有IO，能够运行parallel和分布式测试。不知道它对php的适用性如何，但是如果你可以在内存数据库中测试代码单元并模拟环境，你会更好。

如果您在提交和制作之间有QA / QC或任何人，那么您将无法前往full continuous deployment。关键是您相信您的测试，监控和自动响应（免疫系统）足以消除从您的系统中演变人类的容易出错的过程。

Answer 3

函数之间的所有切换都会降低速度，从而增加部署中的更改量（以及风险）。

根据定义，手动质量门是从一开始就没有建立质量的接受。代码需要稍后审核的唯一原因是因为有些人认为质量已经不够好了。

我正在尝试从管道中删除正式的代码审查，正是出于这个原因。它导致反馈延迟，引用Martin Fowler：

“持续集成的全部意义在于提供快速反馈。没有什么比一个需要很长时间的构建更能吸取CI活动的血液。”

相反，我想让代码审查提交者请求的内容，或者在团队成员编写代码时完成，也许是对XP编程编程。

我认为，一旦将代码合并到源代码控制，应该是您的目标，绝对没有更多的手动干预。

Answer 4

我不知道这是否与PHP相关，但您至少可以用静态分析替换部分代码审查阶段。

代码审查的质量依赖于审阅者的质量，而静态分析依赖于最佳实践和模式，并且是完全自动的。我不是说应该放弃代码审查，我只是认为它可以离线完成。

见

http://en.wikipedia.org/wiki/Static_code_analysis

http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis