持续交付话题的一些讨论和心得

周末参加了在杭州举行的持续交付话题沙龙的讨论，将这次活动中的一些精彩问答和经验警句记录下来供大家参考：

1. ” 持续交付如何让老板看到价值？“，这是当时讨论的比较激烈的话题，大家形成的基本结论是可以通过衡量周期时间来看持续交付前后的变化，如果使用持续交付前的周期时间是1周，运用了持续交付后周期时间变为3天或者更少了那么就为公司提高了竞争力，就比竞争对手更快的退出新产品、功能了。

2. “ 持续交付是公司软件研发综合能力的体现“，它体现了从编码->测试->上线全流程的整体协调和相关工程实践的使用能力。特别是DevOps两部门的融合，持续交付的自动化管道犹如一个个自动化的生产线，只不过最后的输出就是上线的软件。

3. " 让写代码的人专心写代码"，让开发人员分心的事情或者说需要等待的事情不少，例如：等待测试机器/资源、等待测试结果的反馈、等待质量数据反馈。而持续交付可以尽可能的降低开发人员上述的一些等待时间，从而提高生产率。
   

4. “ 通过可视化来影响团队”，有用一个显示器用来显示 Jenkins build pipeline，也有用一个闪烁的红灯来表示构建失败的情况，通过这些可视化的手段来使团队遵循’修复构建失败是第一优先级的事情‘的约定。
   

5. “ 自动化测试的切入点需要开发测试同事一起来决定“，开发和测试同事可以坐在一块吧系统的架构、模块画出来，看看哪些是需要做UT、哪些需要做IT（接口测试/集成测试）等，然后从一个最小部分开始实施，逐步的把自动化测试加入到持续集成中去。

6. 持续交付不是一个最终状态，而是‘在路上’的一个过程，它没有终点，并不是意味着将发布周期从1周缩短为2天就是持续交付了，更重要的是“ 将发布的选择权交给业务部门，而不是IT部门”，所以说持续交付一个不断优化提升的过程，它没有一个业界的‘终点’定义。

正如《 持续交付》一书书中所说 “如果在软件开发中的某个任务令你非常痛苦，那么解决痛苦的方法只有更频繁的去做，而不是回避”，只要我们从思想上能够接受快速失败、快速修改、快速发布的节奏，那么持续交付的理想国就为期不远了。