1.分步骤描述一个持续集成的过程。
每当有人提交代码时，就对整个应用进行构建，并对其执行全面的自动化测试集合。
2.使用分支技术时，能否做到真正的持续集成？持续集成的实践建议提交代码的频率是多少？
使用分支技术不能达到真正的持续集成，持续集成的实践建议提交代码的频率是一天多次。
3.哪三类自动化测试会在持续集成中使用？
单元测试、组件测试和验收测试
4.提交阶段都包括哪几步？建议的时长是多少？
1）是否有构建正在运行，若有等它完成，若失败，需要和团队一起修复再提交代码
2）一旦构建完成且测试全部通过，从版本控制库中将该版本的代码更新到自己的开发环境
3）在自己的开发机上执行构建脚本，运行测试，以确保在机器上的所有代码都工作正常
4）若本地构建成功，将代码提交到版本控制库
5）等待提交构建结果
6）若构建失败，立即修复并转到步骤三
5.提交前的测试又叫什么？
提交前的测试是单元测试
6.如果构建失败了应该做什么？
尽快修复，如果不能尽快修复，需要回滚到版本控制库中前一个可工作的版本上
7.回滚之前规定的修复时间是多久？
可以建议团队以10分钟修复为准，无法修复即做回滚
8.如果构建失败了，只有提交的人才能修改缺陷，这句话对吗？
团队的人都可以修改缺陷，需要推行代码共有
9.分布式团队可以考虑采用哪些工具和实践？
使用共享的版本控制系统和持续集成系统
10.DVCS和集中式VCS的最大不同是什么？
DVCS是每个仓库都包括项目的完整历史，与集中式系统相比较，DVCS引入了一个中间层：在本地工作区的修改先提交到本地库，然后才能推送到其它仓库，更新本地工作区时，需从其它仓库将代码更新到本地库。
简书回魂倒数第9天倒计时。
