持续集成使用的典型场景

在看《持续集成-软件质量改进和风险降低之道》时，读到下面这段话，很有意思，加了一些自己的理解，和大家分享一下。
        Tim是一个java项目15名开发之一，上班来到公司，看到宽屏幕显示器上显示项目实时信息（有一个形象直观实时的构建反馈方式），信息表明，最近一次集成构建几分钟前执行，ci服务器显示成功完成(构建活动是非常频繁的，如果构建失败，就是引发此次构建失败的人的责任，必须马上跟进处理，给构建负责人一顶红帽子也是个不错的主意：))。显示器上列出最新的品质测量指标列表，包括编码/设计标准的坚持情况，代码重复的情况等（对项目品质度量，有很多指标值得关注，甚至写入到规范中）。他看到某个子系统重复代码太多，就对这块代码进行了重构（项目品质度量指标会成为我们做工作计划的重要参考）。在将变更提交svn前，他拉下最新代码，进行一次“私有构建”，构建成功后，他将代码提交（重要的原则：一定在保证用最新代码本地构建成功后才能提交代码）。此时，CI服务器轮询svn库时，发现变更，立即执行集成构建。此次构建先运行自动审查工具，检查所有代码是否符合编码标准。Tim收到电子邮件，通知他违反了编码标准的代码（反馈要及时，准确，信息要充分），他迅速地进行了一些修改，再提交svn。CI服务器再次构建。通过查看CI服务器生成的web报告，Tim发现刚才的代码重构成功减少了子系统重复代码的数量。(工作对项目的贡献及时反馈到开发，对提高积极性也非常有用)
    过了会，另一位开发Lisa走进Tim的办公室。
    Lisa:我觉得您今天早一些时候进行的改动破坏了上一次构建
    Tim：啊。。。。但是我运行测试通过了啊
    Lisa: 哦，我还没来得及写测试，没有验证你的修改对我代码的影响。
    Tim：你坚持了我们为项目建立的代码覆盖率测试指标吗？
   由于这些讨论，他们决定，如何代码覆盖率低于85%，就不要进行集成构建(逐步地完善适合项目约定，同时让大家都认同、遵守这些约定)。且由于与Tim的谈话，Lisa编写了一个UT测试，检测并修复了她发现的问题(测试用例也是在不断地补充完善中，发布一个bug)。集成构建保持“亮绿灯”的状态。
    其他：1.（触发持续集成的原因不只是开发提交代码，还有可能DBA变更数据库，配管更新配置项等）
          2.构建成功的话，意味项目状态良好，可以随时进行发布。如果将发布过程也纳入持续集成，那发布、交付就变得很轻松
        3.用一些有趣、直观的方式来管理项目进度，质量，让枯燥的码农生活变得有趣些。