持续发布（CD）重新认识
CD 持续发布运行有价值，从三个方面来保证
- 需要从CD 本身pipeline 反馈快；
- 代码的质量有保证；
- 核心是发布的产品有价值。
所谓的 快，好，值。
但是CD 持续发布，需要开发的节奏要持续， 那么就不能有大量的的技术债。
- 从架构层面的技术债，就是软件的架构不再适应当前的需求或者编码， 需要架构改进或者说是演化。
- 从代码层面来说，技术债就是代码没有测试覆盖；同时 代码有坏味道。 这些坏味道不去除，这些坏味道会持续使的软件内部质量恶化， 使的软件持续开发不得延续。 需要重构， 然而重构需要测试保护。
1. Fast Feedback
CD 提倡的是 小步快走，持续反馈的理念。 代码至少每天要提交一次，local branch 生命周期尽可能的短， 这样才能体现CD的价值。
-
CD 需要反馈快才有意义，CD的一个衡量指标(KIP)就是下面
- 多长时间发布一次
- 提交一次代码到production 多长时间
- 如果失败，多长时间修复
- 多长时间修复一次
这个KPI与另一组指标 快速，稳定，准确也是对应的。
-
CD pipeline 分解为CI -CD
CI. CI 就是从代码提交到生成最终的artifacts。
最终的artifacts 或许是war， so ， docker image. 这个部分开发人员在日常开发中关注。 其包含 从仓库-编译-测试 - 各种扫描。CD （continuous deployment）
就是从代码构建软件运行的环境（host-environment），以及部署前面步骤的结果部署到这个上面，甚至做一些简单的验证. 这里的构建是从申请虚拟机开始，甚至更底层开始，最好全部自动化。 所谓 infrastructure as a code. 这里面还有一些其他理念cattle vs pet， configuration as code。
常见的一个典型实践就是就是，CI 和CD 分开； 同时各自团队有自己的CI和CD； 而不是share在一起，这样会依赖而且会使反馈变慢。
- CD 涉及到的具体实践层面的东西太多，这里就不展开。 常见的工具就是jenkins， 以及各种插件， docker ，以及搭建cluster 以及调度的 k8s.
2 质量
代码质量不好，CD就无从谈起。
软件质量包含的内部质量和外部质量。外部质量就是可以看到的，常见到的就是用户的bug。 内部质量指的是代码质量，代码是否容易理解，是否容易修改，是否可测，是否有单元测试等，所谓的clean code。
- 测试常见就是金字塔原则，估计现在这个已经没有多大争议。
唯一有问题的是不同测试如何选择？ 根据场景和技能，选择性价比最高的工具。
- Build quality into code
测试只能发现问题，但是更高效的从写代码的时候尽量少进入bug。 所谓敏捷的实践， 比如
PP， TDD，Clean code， refactor， unit Test。 等等。这个需要提高开发人员技能和工程实践能力。这个是关键，但是也是最难的。
3 价值
软件的是商品，其核心是价值。 软件的整个生命周期都要围绕着价值走。软件所谓2件事， do right thing ， do thing right.
关注价值，管理价值，计划价值，构建价值，发布价值 ； 简而言之，软件开发就是价值开发。
这个也是持续发布的最终落脚点。 也是Nature of Software Development的核心。
feature 体现value，软件发布要按照feature by feature去发布。 所以需求要分解，想做高优先级的。 如果不分解低优先级和高优先级的合在一起，没有把持续发布优势彻底发挥。
持续发布feature就需要切蛋糕的一样垂直切分，每一个都是一个端对端的story。
4 持续发布。
开发的节奏会被技术债拖累。 同样就会涉到架构的持续演化和代码的重构。这个前面已经提到。
持续发布，带来的好处是我们期望的，快速发布价值和快速响应市场，快速试错都适合我们期望的。 但是要做到快速发布，如上图所看到的，影响到整个软件开发的生命周期。需求需要分解，slice划分，架构持续演进， 代码要走clean code， 测试要自动化，软件质量构建于开发之中； 部署自动化。 持续发布，完全影响到整个软件的生命周期。
