【发布时间】：2015-06-30 16:50:13
【问题描述】：
我是一名 QA 自动化工程师，我正在研究 docker 作为运行我们测试的潜在方式。
传统上，我们遵循 git flow 方法，基本上你有一个 dev 和一个 master 分支。 Dev 不断将他们的新更改合并到 dev 分支。当我们希望发布时，我们将截断代码，其中当前 dev 分支上的所有内容都被视为下一个版本的一部分。然后运行脚本来创建候选发布版本，并将其部署到登台。需要对发布分支进行任何修复，一旦准备好进入生产环境，新代码就会合并到主控并部署。 Master 重新合并到所有分支，以便一切都是最新的。 （在这里更详细地描述：http://nvie.com/posts/a-successful-git-branching-model/）。
所以我的问题是关于 docker，你需要这个工作流程吗？我想也许有一个如下所述的工作流程：
- 开发人员开始着手开发一项新功能。
- Dev 拉出 master，创建功能分支 - 他的 dev 是否工作 - 单元测试通过，dev 很高兴工作去 QA
- Dev 运行脚本来创建候选版本（如果新代码已被另一个开发者合并到 master，这将涉及再次拉取 master），
- Docker 然后启动一个容器，其中包含多个容器（前端应用程序、数据库实例等）
- 然后针对此候选版本运行测试（单元、api、selenium 集成等），如果成功部署到生产环境。
那么，我是否需要一个传统意义上的 staging env，它始终可用？
【问题讨论】：
-
你的意思是要用开发者的电脑（运行docker容器）替换staging环境吗？
-
嗨，Thomasleveil - 在某种程度上我猜。当开发人员运行脚本以创建候选版本时，将创建暂存环境。我的意思是使用 docker 意味着我们应该能够非常快速地启动与生产相匹配的容器，那么我们是否需要传统意义上的暂存环境？抱歉，如果这不是很清楚，现在只是想了解一下 Docker。