敏捷开发部署过程。质量检查和业主在哪里进行测试？

最近，我一直在大量阅读使用SVN或GIT进行的各种Web应用程序部署过程，以期重新设计我们目前在我的工作地点进行部署的方式。

就像许多种敏捷方法一样，我们假设提交给主服务器或主干的任何东西都已准备就绪。GitHub和Etsy（http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/）都说他们是在此基础上工作的（尽管Etsy实际上有一个暂存环境）。

此过程假定所有单元测试和CI测试都已运行。您在本地和CI上运行测试，然后提交到中继。所以，在这一点上，您的代码在技术上是正确的。

您的代码在技术上可能是正确的，但是用户/功能测试可能会发现更多错误，尤其是在涉及前端测试时。

我的问题是这个。质量检查和企业所有者在哪里测试您实施的功能更改？在提交中继之前是在本地开发计算机上还是在QA /登台计算机上？

如果您有一台在主干上运行的登台计算机，并且假定提交到主干的所有代码都已准备好投入生产……嗯..那么，什么时候该代码已被批准，并且可以从技术和业务上投入生产透视？如果您只有一台登台计算机，并且有许多开发人员，并且要对这些代码进行质量检查，那么随着许多开发人员的更改可能正在等待注销，您如何从主干进行部署。

我很想听听其他人如何做到这一点？

不管是好是坏，我通常会在针对分支机构进行测试的情况下看到此操作，并且业务签核是合并到部署主体的检查点。

我已经看到这是通过在具有单独的“已部署”分支的“主”上进行开发，或将主作为“已部署”的开发“功能”分支上完成的。

工作流最终看起来像这样：

• 编码一些东西
• 运行本地测试
• 签到工作分支
• （可选）构建服务器构建蚂蚁测试
• 质量检查/业务测试
• 错误修正（循环回到顶部）
• 合并部署分支
• 部署

有些人只在一个分支中工作，但是如果您要进行手动测试，将变得很困难。我遇到的大多数人都基于这样的假设，即可以在提交上部署的任何事情也可以在单个主干中完成，它们所做的事情很小，或者具有大量的自动化测试，或者他们认为这次对话中的“部署”旨在成为测试服务器的构建，并且测试服务器和生产之间发生的质量检查流程将单独处理。

我们在同一功能分支上进行了自动验收测试。候选发布时，它将包括您运行的自动测试，以查看功能是否通过。您还测试候选发布。当一切都过去时，您可以通过合并来提升它。

有关此过程的更多信息，请参见：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

还要检查评论。

希望这可以帮助，

亚当

通常，在代码完美之前等待提交是收回版本控制系统优势的一半时间。（无需过多说明，我要说的是，除非允许一个人到VCS进行多次签入，否则没有办法恢复我自己的工作！）因此，作为一种惯例，我们总是要求人们保持签到（在他们的SVN分支内）也可以是本地提交（如果是GIT，则尽可能多）。实际上越多越好。

但是，当到达一切似乎都已完成并经过测试的地步时，我们将其称为发布，然后将其与主干合并。本质上，QA可以通过HEAD在分支的分支上重新签出来对RC进行认证，如果他/她是Okey的，则将其与主干合并。

因此，从本质上讲，我们使用任务分支或私人分支的概念，以便人们可以根据需要自由进行签入。同时，中继线相对没有任何损坏的登机手续。