读书：软件交付通识

Martin Fowler是这么描述持续部署的：持续部署意味着每个通过部署流水线的变更都被自动地部署到生产环境中，于是每天都会有若干次生产环境部署。

 

经典的持续集成方式是：开发人员可以随时向集成分支提交代码改动，而每次提交代码改动时都会触发一系列轻量级的自动化测试。

 

敏捷是在纠正软件交付过于强调工程化、标准化的倾向，降低需求、开发、测试等之间的协作成本；而DevOps则是更进一步降低开发团队、运维团队甚至安全团队（DevSecOps）之间的协作成本；精益模式则是将客户也纳考虑范畴，更加宽泛地囊括整个价值交付过程中客户与企业之间的协作问题，减少时间浪费，减少无价值良妃，关注客户价值流动。

 

传统思维方式是追求资源效率最大化：审视每个步骤和环节的产出效率，追求单位成本的最大产出。而在VUCA时代往往更重要的是价值流动效率最大化：从用户角度，审视创造用户价值的过程是否已经足够顺畅。

 

特性团队是指长期的、具备交付价值所需的各种角色的、可以协同完成完整用户价值交付的团队。

 

每次代码改动提交，都应该是逻辑上完成了一个独立的改动后进行的提交，并且该提交不影响原有程序正常的执行。因此每天强制代码提交次数的规定，从度量角度上是有一定问题的。

 

“负压驱动”找到速度与质量的平衡点：如果在生产环境遇到很容易发现的问题，那么说明测试人员在release分支上的测试不够充分；如果在release分支上测试人员进行的正式测试经常遇到很容易发现的问题，那么说明在develop分支上的开发自测还不足够。

 

每当一个特性分支被合入develop分支后，就自然构建一个新版本号，这个新版本就对应一个特性列表，该列表中包含了自从上次发布以来所有合入的新特性。

 

源代码、构建和制品三者间需要建立关联关系，可以定位某次构建将哪个版本的源代码构建成了某些制品。制品、部署和环境三者间也需要建立关联关系，可以定位某次部署将哪个制品部署到了哪些环境中。

 

因工作关系近期进行了CMMI和Agile的比较，从大的方面进行了一些区分。CMMI更多的是甲方的视角，担心项目失败，担心失败后的后果无法承担，担心项目无法一次性成功；而Agile更多的是乙方的视角，担心交付的东西没有创新，担心交付的速度慢人一步，担心交付的东西不是客户最终期望的。