自动化的高级追求: Prow 是什么?Kubernetes 为什么需要它

why? 故事是从这个 proposal 开始idea~ 🤖 OpenIM cicd robot machine proposal Prow是基于Kubernetes的CI/CD系统。作业可以由各种类型的事件触发,并将其状态报告给许多不同的服务。除了作业执行,Prow还以策略执行、通过 /foo 风格命令的聊天操作和自动PR合并的形式提供GitHub自动化。 有关 Golang 文档,请参阅 GoDoc。请注意,这些库仅供prow使用,我们不会尝试保留向后兼容性。 Kubernetes 专门为 Prow 提供了网页命令查询: https://prow.k8s.io/command-help 关于Prow如何运行作业的简要概述,请参阅 Prow作业的生命周期。 要查看Prow的常用用法和交互流,请参见拉取请求交互序列图。 hello world 最简单的一个上手案例莫过于 pull request 。 提出一个拉取请求(以下简称PR)。在PR正文中,可以随意添加区域标签(如果合适),例如 /area <AREA> 。标签列表在这里。也可以随意推荐一位评论者 /assign @theirname 。 一旦你的审阅者满意,他们会说 /lgtm ,这将应用 lgtm 标签,如果他们是OWNER,将应用 approved 标签。 approved 标签也将自动应用于所有者打开的PR。如果你和你的审阅者都不是OWNER,请 /assign 某个所有者。如果你的PR有 lgtm 和 approved 标签,没有任何 do-not-merge/* 标签,并且所有测试均通过,则PR将自动合并。 查看测试结果 Kubernetes TestGrid 显示历史测试结果 在 testgrid/config.yaml 配置自己的 testgrid 仪表盘 Gubernator 格式化每次运行的输出 PR Dashboard 查找需要注意的 PR Prow 安排测试并更新问题 Prow 响应 GitHub 事件、定时器和在 GitHub 评论中给出的手动命令。 prow dashboard 显示当前正在测试什么 在 config/jobs 配置 prow 运行新测试 Triage Dashboard 汇总故障 将故障集群在一起 搜索跨作业的测试失败 在特定的测试和/或作业的 regex 中过滤失败 Velodrome 指标跟踪作业和测试健康状况。 Kettle 进行收集,metrics 进行报告,velodrome 是前端。 功能和特性 prow 的功能很强大,甚至是比 actions 更加出众。可以测试、批处理、工件发布的作业执行。...

September 16, 2023 · 4 分钟 · 796 字 · 熊鑫伟,我

我如何设计 DevOps 下的 OpenIM 标准开发流 & 敏捷体系 & 精益模式

DevOps DevOps 🔥 DevOps是一种软件开发和运营的文化和方法论,旨在通过自动化和协作来缩短软件开发周期和提高软件质量。 DevOps(Development和Operations的混成词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 为什么 OpenIM 需要 DevOps? 我想用一句话来概括,DevOps 能解决 OpenIM 当前的团队管理,能高效组织团队,并且能通过 自动化 工具协作于沟通。 从而实现用更少的浪费、更频繁的交付更稳定的产品。 最开始的 OpenIM 是什么样子的? 找到了之前的一个很古老的版本,链接是:https://github.com/OpenIMSDK/Open-IM-Server/tree/test-tuoyun 几乎存在 commit 信息丢失,因为信息不全导致代码无法跟踪问题,导致文档缺失,代码不规范等一系列的问题。 我们跨越了从原始社会到传统的协作方式,再到后面的 devops 为什么说及时到现在,我依旧没有将 OpenIM 转变为 devops,一个很明显的判断标准,每一次运维和交互工作依旧需要我手动去做,无疑是区分了 dev 和 ops 的职责。不仅仅让成本变高,效率变低,更重要的是团队没有了更清晰的定位。 那么我后面的计划如何? 不管是 prow, actions, 等等 CI 工具,以及各种 ops(gitops, aiops, chatops,) 也不管是各种设计的 自动化 以及 自动化管理工具,自动化交互工具。 无疑他们是一套体系: 提供无感知的开发环境,无论交付是否频繁,每一个 feature 的 PR 都能快速的,规范并且经过大量自动化测试,更加快速上线,也能更快地响应客户需求。每一次发布的变更变少,所以风险,以及合并的冲突,工作量就变少。而且代码 code review 更方便,代码质量和团队水平提升很高的档次。 🔥 OpenIM 当时我的设计理念是 main 分支作为一个类似于传统的 dev 分支,保证代码的最新以及基本可靠,release-v* 分支作为稳定的分支。 DevOps 最重要的就是自动化,和自动化运维。非常鼓励自动化,甚至可以让开发者即使不会任何运维也能去走整套自动化的流程。 OpenIM 的团队约束制定:https://traveling-thistle-a0c.notion.site/OpenIM-standardization-ebd0c1529ab54e4fb92840e67a73aac1?pvs=4...

September 2, 2023 · 3 分钟 · 458 字 · 熊鑫伟,我