帮助我改进我的连续部署工作流程 [英] Help me improve my continuous deployment workflow

问题描述

我一直在开发一个工作流程，用于练习一个基本上自动化的。上述工作流程图表是受Android OS项目启发的。

解决方案

有多少人在使用它？如果你只有10或20个开发人员，我不确定这样一个精心设计的工作流程将是有意义的。如果你管理500，肯定...

我个人的感觉是KISS。保持简单，愚蠢...你想要一个既高效又重要的过程：简单。如果它很复杂，没有人会做正确的，或在时间部分将滑倒。如果你简单，它将成为第二自然，几个星期后，没有人会质疑的过程（嗯，它的语义的任何方式）...

其他个人感觉总是运行所有的UNIT测试。这样，您可以跳过流程图中的整个决策树。毕竟，什么是更昂贵，几分钟的CPU时间，或大脑周期来了解部分测试通过和大规模测试失败之间的差异。记住，失败是一个失败，没有实际的原因，代码应该显示给审查者有可能失败的构建。

现在，Selenium测试通常是相当昂贵的，所以我可能同意推送它们，直到审查者批准。但你需要考虑那个...

哦，如果我实现这个，我会把一个正式的QC阶段。我想让人类测试者来看待任何正在发生的变化。是的，Selenium可以验证你知道的事情，但只有一个人可以找到你没有想到的东西。将他们的发现反馈到新的Selenium和集成测试中，以防止回归...

I've been developing a workflow for practicing a mostly automated continuous deployment cycle for a PHP project. I'd like some feedback on possible process or technical bottlenecks in this workflow, suggestions for improvement, and ideas for how to better automate and increase the ease-of-use for my team.

---

Core components:

• Hudson CI server
• Git and GitHub
• PHPUnit unit tests
• Selenium RC
• Sauce OnDemand for automated, cross-browser, cloud testing with Selenium RC
• Puppet for automating test server deployments
• Gerrit for Git code review
• Gerrit Trigger for Hudson

---

EDIT: I've changed the workflow graphic to take ircmaxwell's contributions into account by: removing PHPUnit's extension for Selenium RC and running those tests only as part of the QC stage; adding a QC stage; moving UI testing after code review but before merges; moving merges after the QC stage; moving deployment after the merge.

This workflow graphic describes the process. My questions / thoughts / concerns follow.

My concerns / thoughts / questions:

• Overall difficulty using this system.

• Time involvement.

• Difficulty employing Gerrit.

• Difficulty employing Puppet.

• We'll be deploying on Amazon EC2 instances later. If we're going about setting up Debian packages with Puppet and deploying to Linode slices now, is there a potential for a working deployment on Linode to break on EC2? Should we instead be doing our builds and deployments on EC2 from the get-go?

• Another question re: EC2 and Puppet. We're also considering using Scalr as a solution. Would it make as much sense to avoid the overhead of Puppet for this alone and invest in Scalr instead? I have a secondary (ha!) concern here about cost; the Selenium tests shouldn't be running that often that EC2 build instances will be running 24/7, but for something like a five-minute build, paying for an hour of EC2 usage seems a bit much.

• Possible process bottlenecks on merges.

• Could "A" be moved?

Credits: Portions of this workflow are inspired by Digg's awesome post on continuous deployment. The workflow graphic above is inspired by the Android OS Project.

解决方案

How many people are working on it? If you only have maybe 10 or 20 developers, I'm not sure it will make sense to put such an elaborate workflow into place. If you're managing 500, sure...

My personal feeling is KISS. Keep It Simple, Stupid... You want a process that's both efficient, and more important: simple. If it's complicated, either nobody is going to do it right, or after time parts will slip. If you make it simple, it will become second nature and after a few weeks nobody would question the process (Well, the semantics of it anyway)...

And the other personal feeling is always run all of your UNIT tests. That way, you can skip a whole decision tree in your flow chart. After all, what's more expensive, a few minutes of CPU time, or the brain cycles to understand the difference between the partial test passing and the massive test failing. Remember, a fail is a fail, and there's no practical reason that code should ever be shown to a reviewer that has the potential to fail the build.

Now, Selenium tests are typically quite expensive, so I might agree to push those off until after the reviewer approves. But you'll need to think about that one...

Oh, and if I was implementing this, I would put a formal QC stage in there. I want human testers to look at any changes that are being made. Yes, Selenium can verify the things you know about, but only a human can find things you didn't think of. Feed back their findings into new Selenium and Integration tests to prevent regressions...

这篇关于帮助我改进我的连续部署工作流程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！