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

我一直在开发一个工作stream程来练习一个PHP项目的大部分自动化的连续部署周期。 我想就这个工作stream程中的可能的stream程或技术瓶颈提出一些反馈意见,改进build议,以及如何更好地自动化和提高我的团队的易用性。


核心组件

  • Hudson CI服务器
  • GitGitHub
  • PHPUnitunit testing
  • Selenium RC
  • Sauce OnDemand用于Selenium RC自动化,跨浏览器,云testing
  • 用于自动化testing服务器部署的Puppet
  • Gerrit的Git代码审查
  • Gerrit Trigger Hudson

编辑 :我已经改变了工作stream程graphics,以考虑到ircmaxwell的贡献:删除PHPUnitSelenium RC的扩展,并运行这些testing只作为QC阶段的一部分; 增加一个QC阶段; 在代码审查之后但在合并之前移动UItesting; QC阶段之后进行合并; 合并后移动部署。

该工作stream程graphics描述了该过程。 我的问题/想法/关注随之而来。

持续部署工作流程

我的关注/想法/问题

  • 使用这个系统的总体困难。

  • 参与时间

  • 使用Gerrit困难。

  • 难以雇佣Puppet

  • 稍后我们将在Amazon EC2实例上进行部署。 如果我们现在正在使用Puppet设置Debian软件包并部署到Linode切片,那么Linode上的工作部署是否有可能在EC2上突破? 我们是否应该从一开始就在EC2上进行构build和部署?

  • 另一个问题是: EC2Puppet 。 我们也在考虑使用Scalr作为解决scheme。 为了避免Puppet的开销,为了避免这种情况的发生,让Scalr投资于Scalr会有多大意义? 我有一个次要的(哈!)在这里关心成本; Seleniumtesting不应该经常运行 EC2构build实例将全天候运行,但对于像5分钟构build这样的东西,花费一个小时的EC2使用似乎有点多。

  • 合并时可能的stream程瓶颈。

  • “A”可以移动吗?

积分 :这个工作stream程的一部分是由Digg的真棒张贴在持续部署的启发 。 上面的工作stream程图是受Android OS项目启发的 。

4 Solutions collect form web for “帮助我改进我的持续部署工作stream程”

有多less人在工作呢? 如果你只有10到20个开发人员,我不确定把这样一个精心制作的工作stream程到位是否合理。 如果你pipe理500,当然…

我个人的感觉是KISS。 保持简单,愚蠢…你需要一个既高效又重要的过程:简单。 如果情况复杂的话,要么没有人会这么做,要么就是在一段时间之后, 如果你简单的话,它将成为第二性质,几个星期后,没有人会质疑这个过程(无论如何,它的语义)。

而另一个人的感觉总是运行你所有的UNITtesting。 这样,您可以跳过stream程图中的整个决策树。 毕竟,更昂贵的是,几分钟的CPU时间,或者脑循环来理解部分testing通过和大规模testing失败之间的差异。 请记住,失败是一个失败,没有实际的理由代码应该显示给审查,有可能会失败的构build。

现在,seleniumtesting通常是相当昂贵的,所以我可能会同意把这些testing推迟到评审员批准之后。 但是你需要考虑那个…

哦,如果我正在实施这个,我会在那里做一个正式的QC阶段。 我希望人类testing人员查看正在进行的任何更改。 是的,Selenium可以validation你所知道的事情,但只有一个人可以find你没有想到的事情。 将他们的发现反馈到新的Selenium和集成testing中,以防止回归…

重要的是让你的testing非常快速 ,即没有IO和运行并行和分布式testing的能力。 不知道如何适用于PHP,但如果你可以在内存数据库testing单元的代码和模拟环境,你会更好。

如果你有一个质量保证/质量控制或任何人之间的承诺和生产之间的方式,你将有一个问题得到一个完整的连续部署 。 关键是您的testing,监控和自动响应(免疫系统)足以消除容易出错的过程,从您的系统中演变人类。

所有function之间的切换都会导致事物减速,并因此增加部署所需的更改量(从而增加风险)。

从定义上来说,手动质量门是质量从一开始就没有build立起来的一种接受。 代码需要稍后审查的唯一原因是因为有人认为质量已经不够好了。

我正在尝试从我们的pipe道中删除正式的代码审查正是由于这个原因。 这会导致反馈延迟,并引用Martin Fowler的话:

“持续整合的重点在于提供快速的反馈,没有什么比一个需要很长时间的构build更能吸引CI的活动。

相反,如果需要,我想让代码审查提交者的请求,或者在编写团队成员的时候完成,也许是la XP对编程。

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

我不知道这是否与PHP相关,但是至less可以用静态分析replace至less一些代码审查阶段。

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

看到

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

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

  • 如何使用Twitter Bootstrap构build2列(固定stream体)布局?
  • 如何在C#中读写文件
  • 错误“此stream不支持查找操作”在C#
  • 如何从string生成stream?
  • 如何使用Laravelstream利的查询生成器来select计数?
  • 将环境variables传递给stream浪shell供应商
  • “参数无效”exception加载System.Drawing.Image
  • fprintf,printf和sprintf之间的区别?
  • 更改cin的分隔符(c ++)
  • 如何导出一个Vagrant虚拟机来传输它
  • Laravel - 雄辩或stream利的随机排