Tag: seleniumrc

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

我一直在开发一个工作stream程来练习一个PHP项目的大部分自动化的连续部署周期。 我想就这个工作stream程中的可能的stream程或技术瓶颈提出一些反馈意见，改进build议，以及如何更好地自动化和提高我的团队的易用性。 核心组件 ： Hudson CI服务器 Git和GitHub PHPUnitunit testing Selenium RC Sauce OnDemand用于Selenium RC自动化，跨浏览器，云testing 用于自动化testing服务器部署的Puppet Gerrit的Git代码审查 Gerrit Trigger Hudson 编辑 ：我已经改变了工作stream程graphics，以考虑到ircmaxwell的贡献：删除PHPUnit的Selenium RC的扩展，并运行这些testing只作为QC阶段的一部分; 增加一个QC阶段; 在代码审查之后但在合并之前移动UItesting; QC阶段之后进行合并; 合并后移动部署。 该工作stream程graphics描述了该过程。 我的问题/想法/关注随之而来。 我的关注/想法/问题 ： 使用这个系统的总体困难。 参与时间 使用Gerrit困难。 难以雇佣Puppet 。 稍后我们将在Amazon EC2实例上进行部署。 如果我们现在正在使用Puppet设置Debian软件包并部署到Linode切片，那么Linode上的工作部署是否有可能在EC2上突破？ 我们是否应该从一开始就在EC2上进行构build和部署？ 另一个问题是： EC2和Puppet 。 我们也在考虑使用Scalr作为解决scheme。 为了避免Puppet的开销，为了避免这种情况的发生，让Scalr投资于Scalr会有多大意义？ 我有一个次要的（哈！）在这里关心成本; Seleniumtesting不应该经常运行， EC2构build实例将全天候运行，但对于像5分钟构build这样的东西，花费一个小时的EC2使用似乎有点多。 合并时可能的stream程瓶颈。 “A”可以移动吗？ 积分 ：这个工作stream程的一部分是由Digg的真棒张贴在持续部署的启发 。 上面的工作stream程图是受Android OS项目启发的 。