持续集成随想【一】

[chenkan]

实践了一段时间持续集成，最近，又在看这方面的书，点滴记录一下。

[chenkan]

持续集成的一个关键目标就是提供集成构建的反馈信息。
怎样的反馈才是好反馈？我想：

• 可读性强，即使是不参与这项工作（老板、运营、不直接相关的开发与QA，等）的人也可以快速理解反馈的大意
• 分级别，把各种失败按照不同优先级区分开，使大家可以酌情安排处理（例如：邮件标题加【紧急】【P0】【P1】等字眼，测试用例按照【critical】【major】【normal】分列）
• 冲击力强，可以迅速引起大家关注，介入处理，例如：使用大屏幕作为持续集成看板see this link
• 日志丰富，重现能力强
• 提供SVN（GIT）changelog，最好还可以有数据库变更、测试环境配置变更信息
• 减少，乃至杜绝假警报
• 待续

[chenkan]

如何缩短开发提交代码 - Jenkins执行构建、测试失败 - 查证原因 - 修复验证这个环？？？

[chenkan]

从工具层面讲，可以把持续集成的工具链当成一个产品来发展，做到极致，所谓

人见人爱，花见花开
结实耐操，方便好使

从而引导大家平滑切换到持续集成的流程下

工具创造需求，就像电视机

[chenkan]

回到单元测试，我们目前会把用例执行邮件（基于TestNG）发给大家，我觉得还有这几个方面可以改进：
【1】展示两次构建之间的changelog及committee
【2】展示每个用例的维护者 / 作者
【3】对于失败用例，直接贴上用例的代码片段
【4】对于失败用例，再贴上用例运行时的执行步骤与变量堆栈

[chenkan]

有时候，须要听取大家的意见改进持续集成；
有时候，须要以前瞻性的眼光及洞察力，挖掘出有价值的改进点，做出来推广

[chenkan]

静态代码检查

于开发团队，可以树立公约，建立共性，增进沟通（读代码 ~= 沟通），凝聚力量
于开发个人，可以借助工具实现一些为大家所认可的优质coding实践，减少犯错几率，提升自身职业素养
于产品代码，可以造就内在美，由内而外提升品质

母鸡下蛋，老牛耕田，码农抠碇，你丫的不好好写代码，对得起公司发的钞票吗？

[chenkan]

持续集成的另外一个关键特征是速度
如何在持续集成过程中做好广度、深度、速度的权衡？？？

[chenkan]

持续集成的本质是向开发人员及项目风险承担者提供及时有效的反馈。
我们老是纠结于可以给开发提供哪些好处，其实项目风险承担者也很关键。那么：

谁在承担风险，
何种风险，
Ta须要什么样的反馈呢？

[chenkan]

持续集成就像锻炼身体，好处谁都懂，
但是要靠自觉，会有痛苦，无法速成

[chenkan]

看看周边，经常锻炼的，多是根基已稳的老员工、头目级别；
产品、项目也是类似，还在为生存而战的，毕竟难下决心

[chenkan]

持续集成

不是：一项扔给一个【持续集成负责人】就可以搞定的实践
而是：整个技术团队的同事都应该参与进来，实现【共建共赢】的实践

[chenkan]

把一堆需求捆绑在一起开发、测试、上线与流水线般将需求完成一个上线一个，
这两种模式之间商业价值相差何其大也！

从开发层面，要求可以将需求妥善解耦，并行开发；
从测试层面，瓶颈应该在回归测试

全面又有信心的自动化回归测试 + 完善的持续集成体系，可以帮助我们实现这个价值

[chenkan]

关于风险

持续集成的一个主要作用就是降低风险
风险可以是项目视角的，例如：需求无法被及时实现，上线被迫延迟；人力资源不足，又无法及时补充
也可以是开发视角的，例如：上线任务重，导致开发质量差，技术债累积，新功能Bug多，又引发大量回归性问题
也可以是测试视角的，例如：需求变动大，加塞任务多，测试时间压缩严重，没时间全面回归
从正义的角度看，这三个风险是一致的，是一条船上的，你好我好大家好；
从邪恶的角度看，为了降低项目风险，可以压榨技术团队的下班时间，
为了降低开发风险，可以把脏活、累活抛给测试，
为了降低测试风险，可以不断给开发提自测要求，
从现实看，基本是技术团队为项目做牺牲，测试为开发做牺牲

当我们开展持续集成的时候，就要不断提醒自己：
我在哪个视角？
我的合作方在哪个视角？
我们能够保持目标一致吗？
是不是只有站对了队，才能把工作做好？
如果测试团队不属于产品，测试本身又该如何站队？
如何实现双赢，乃至多赢？