我一直在开发一个工作流程来练习自动化程度最高的 continuous deployment PHP 项目的周期。我想要一些关于此工作流程中可能存在的流程或技术瓶颈的反馈、改进建议以及如何更好地自动化并提高团队易用性的想法。
核心组件:
-
HudsonCI服务器 Git和GitHub-
PHPUnit单元测试 -
Selenium RC -
Sauce OnDemand使用Selenium RC 进行自动化、跨浏览器的云测试
-
Puppet用于自动化测试服务器部署 -
Gerrit用于 Git 代码审查 -
Gerrit Triggerhudson
编辑:我已更改工作流图形以考虑 ircmaxwell 的贡献，方法是:删除 PHPUnit 的 Selenium RC 扩展和仅作为 QC 阶段的一部分运行这些测试；增加一个QC阶段；在代码审查之后但在合并之前移动 UI 测试；在 QC 阶段之后移动合并；合并后移动部署。
此工作流程图表描述了流程。接下来是我的问题/想法/疑虑。
我的顾虑/想法/问题:
使用这个系统的总体难度。
时间投入。
使用
Gerrit的难度。使用
Puppet的难度。稍后我们将在
Amazon EC2实例上进行部署。如果我们现在要使用Puppet设置Debian软件包并部署到Linode切片，是否有可能在Linode要在EC2上中断？我们是否应该从一开始就在EC2上进行构建和部署？另一个问题是:
EC2和Puppet。我们也在考虑使用 Scalr 作为解决方案。仅仅为此避免Puppet的开销并改为投资 Scalr 是否有意义？我对成本有一个次要的(哈!)关注；Selenium测试不应该经常运行EC2构建实例将 24/7 运行，但是对于像五分钟构建这样的东西，支付一小时的EC2使用费用似乎有点多。合并时可能存在流程瓶颈。
可以移动“A”吗？
致谢:此工作流程的部分内容是 inspired by Digg's awesome post on continuous deployment .上面的工作流图是inspired by the Android OS Project .
最佳答案
有多少人在做这件事？如果您只有 10 或 20 名开发人员，我不确定将如此复杂的工作流程落实到位是否有意义。如果你管理 500，当然......
个人感觉是KISS。保持简单，愚蠢...您想要一个既高效又重要的过程:简单。如果它很复杂，要么没有人会把它做对，要么时间一长零件就会滑落。如果你让它变得简单，它将成为第二天性，几周后没有人会质疑这个过程(好吧，无论如何它的语义)...
另一种个人感觉是始终运行所有 UNIT 测试。这样，您就可以跳过流程图中的整个决策树。毕竟，更昂贵的是几分钟的 CPU 时间，或者大脑循环来理解部分测试通过和大量测试失败之间的区别。请记住，失败就是失败，没有实际理由将代码显示给有可能导致构建失败的审阅者。
现在，Selenium 测试通常非常昂贵，所以我可能同意推迟这些测试，直到审阅者批准。但是你需要考虑那个……
哦，如果我要实现这个，我会在那里放一个正式的 QC 阶段。我希望人工测试人员查看正在进行的任何更改。是的，Selenium 可以验证您知道的事情，但只有人类才能找到您没有想到的事情。将他们的发现反馈到新的 Selenium 和集成测试中以防止回归......
关于php - 帮助我改进我的持续部署工作流程，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3703373/