使用 Dapr 缩短软件开发周期
Microsoft DevOps 文档里的文章（//docs.microsoft.com/zh-cn/azure/devops/report/dashboards/cycle-time-and-lead-time?view=azure-devops）中的这张图片在给我们介绍了 什么是周期时间 以及它如何影响我的项目流时非常有影响力。
第一次输入 “正在进行” 或 “已解决” 状态类别到输入 “已完成” 状态类别，计算周期时间。 当开发人员编写代码时，能够快速验证更改并进行修订对于保持较短的周期时间至关重要。
丰田生产方式之父大野耐一曾经说过：我们唯一要做的就是降低从接到订单到交付产品给客户的周期时间。周期时间的降低可以有效保证软件的按时交付 。所以周期时间是软件交付的核心目标。
特别是微服务的设计和开发，通常需要达成下列4个目标：
- 构建的API 驱动设计的微服务
- 一切都可以在本地构建、测试和运行，而无需复杂的设置。
- 云端和本地依赖关系的等效性
- 设备环境无关，可以自由在Windows,Linux,Mac 之间切换。
我们借助于Dapr 可以非常容易的达成以上4个目标， 使用 Docker Compose 和 Dapr 技巧进行本地开发，测试和生产环境运行于Kubernetes， Kubernetes现在是各大云厂的标配服务。借助于Dapr 的语言无关性，平台无关性，我们可以在环境上尽量的缩短了时间，保持较短的周期时间交付软件。
我们可以在大脑里面来回顾一下我们的开发过程，对于每个任务/代码更改：
- 开发人员会将更改部署到生产环境
- 如果发现任何错误，请重新部署旧 镜像
- 在本地修复所有更改
- 推动其分支以生成可部署的内部版本，然后返回到 （1）
只有当开发人员脱离这个循环时，他们才能将他们的代码签入主程序。这个过程太疯狂了！仅第 4 步在镜像创建和部署之间就花费了大约 20 分钟。两三个遗漏的错误可能会使开发人员在一天中花掉大约1个小时，并且考虑到除了日常工作之外，我们都在从事这项工作，这扼杀了生产力。还有可能要考虑到部署对依赖项的更改所需的周期，此处的部署花费了更长的时间。
