《持续交付》第一章

以前认为在一个软件开发过程中,代码写完了重头戏就过去了,可能真的是因为没有经历过从软件开发完成到交付给客户的这个过程,恰好最近我们的课程设计编码已经完成,正在考虑部署交付的问题,拿起这本书算是比较合时宜吧!
这本书关注的点是构建,部署,测试和发布过程,中心模式是部署流水线,即就是一个软件从构建,部署,测试到发布的自动化实现.

发布反模式

• 手工部署软件:人并非机器,很难避免一些人为操作的失误,更别说执行顺序和时机也会引起一些意料之外的后果.
• 开发完成之后才向类生产环境部署:当大家都以为软件开发完成大时候殊不知运维人员可能是第一次见到这个软件,或者测试环境和之前的开发环境大不相同等等各种问题.
• 生产环境的手工配置管理:每次准备运行环境都需要巨长的时间,多次部署到试运行环境都很成功,但一到生产环境就失败等等.

如何做得更好

频繁且自动化的发布软件

• 每次修改都应该触发反馈流程:任何部分的修改可能都是牵一发而动全身,所以每一次的修改应当触发全面而又自动化的测试.
• 尽快接收反馈:整个流水线的提交阶段的测试和提交阶段之后的测试是不同的.------------不太理解
• 交付团队应当根据反馈做出反应:将反馈的过程以及结果可视化,及时更新,要让团队的每个人都能注意到并且意识到它的重要性.才会做出想应的调整.

何时为可发布版本

并不是你说你准备好了一切软件才可发布,客户随时想要验收成果,代码库中的代码都应当是可发布版本,对于可发布版本,我的理解是可以不完整,但不能出现bug.
所以每一次的提交都应当是可以被发布的,提交需谨慎.

软件交付的原则

• 将几乎所有事情自动化
  只有通过自动化很多事情才能是可控的,也只有更广泛地实现自动化,宝贵的人力才能被解放出来做更有价值的事情.
• 把所有东西都纳入版本控制
  这样做的目的是将开发人员在开发过程中自动达成的某种不成文的规定或者说某种默契可视化出来,让一个第一次见到这个软件的人也能规范正确地去运行整个程序.
• 提前并频繁地做让你感到痛苦的事
  这条原则我觉得对于很多事都是适用的,在软件交付领域它当然是一条不可撼动的原则,比如从一开始就加入测试,从一开始就频繁地集成,从一开始就做到小步提交,这些看似烦人的条条框框实际上却让后边的路越来越平坦.
• 内建质量
  越早发现bug,修复的成本就越低,这也很好地解释了上一条原则.
• 'DONE'意味着已发布
  没有快完成或者完成了百分之多少这种说法,只有完成或者未完成,只要没有发布,就是未完成,因为在没有发布时,你永远不知道后边还有百分之多少的事情等着你去做.
• 交付过程是每个成员的责任
  我认为这条原则更多地时说团队合作集体意识吧,一旦一个团队形成,那么荣辱共享,做得好是所有人的功劳,出现意外也不能急着指责某一个人,大家一定是有同一个目标的.
• 持续改进
  这条原则很熟悉啊,团队成员定期做retro,保持做得好的地方,改进有缺陷的地方,并且每个改进都要指定一个owner,由他负责跟进.是我们也一直在做的事情,个人觉得将任何一个改进点都分配到个人真得是非常重要.
  今天才知道原来这就是戴明环:计划-执行-检查-处理.