疯狂：

　　一键恢复生产环境

　　通过下面问题进一步了解团队的部署及发布现状：

　　上线流程是什么样的?

　　是否需要通过work文档，邮件或是一个在线系统传递上线步骤或参数?

　　如何监测部署的质量?

　　如何做回滚操作?

　　如何向开发环境部署?有那些步骤?需要多少人工参与?

　　如何向测试环境部署?有那些步骤?需要多少人工参与?

　　有那些用于部署的脚本?

　　团队成员各自的部署环境有什么区别?

　　如何选择合适的构建做部署?

　　6 团队习惯维度

　　入门：

　　至少有一个人随时知晓构建状态

　　阶段性代码提交习惯

　　专人维护持续集成平台和脚本

　　新手：

　　专人看护平台构建状态

　　小工作单元完成后即时合并到目标分支

　　所有人知晓当前的构建状态

　　构建失败后被及时修复或回滚，失败期间没人提交与修复构建无关的代码。

　　签入前做本地自动化验证

　　团队成员签入代码前做相同的本地验证

　　失败构建不过夜

　　中等：

　　失败构建修复时间少于半个小时。

　　由提交人负责修复失败构建，每个人都关注构建状态。

　　团队成员都写较为全面的单元测试

　　每人每天向目标分支做至少一次对小工作单元的有效提交。

　　团队清楚持续集成平台和脚本内容，每个人都可以维护。

　　进阶：

　　交付团队全员对持续集成平台的稳定构建负责。

　　交付团队全员负责持续集成脚本开发。

　　疯狂：

　　1小时左右向目标分支做一次对小工作单元的有效提交，且很少发现构建失败。

　　通过下面问题进一步了解团队的部署及发布现状：

　　RD如何定义自己工作完成的含义?

　　团队签入代码的规范是什么?

　　是否在签入代码前运行本地构建?

　　如何确保失败的平台构建有人处理?是签入代码的人处理吗?

　　构建失败的频率是多少?

　　团队中谁维护自动化构建脚本?

　　团队中谁维护CI平台?CI平台有那些权限控制?

　　团队如何提高每个人的单元测试水平?