使用 Dapr 缩短软件开发周期

Microsoft DevOps 文档里的文章(https://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. 开发人员会将更改部署到生产环境
  2. 如果发现任何错误,请重新部署旧 镜像
  3. 在本地修复所有更改
  4. 推动其分支以生成可部署的内部版本,然后返回到 (1)

只有当开发人员脱离这个循环时,他们才能将他们的代码签入主程序。这个过程太疯狂了!仅第 4 步在镜像创建和部署之间就花费了大约 20 分钟。两三个遗漏的错误可能会使开发人员在一天中花掉大约1个小时,并且考虑到除了日常工作之外,我们都在从事这项工作,这扼杀了生产力。还有可能要考虑到部署对依赖项的更改所需的周期,此处的部署花费了更长的时间。

原文链接:,转发请注明来源!