云原生CLI【免费下载链接】openebsA popular widely deployed Open Source Container Native Storage platform for Stateful Persistent Applications on Kubernetes.项目地址https://gitcode.com/gh_mirrors/op/openebs点击查看免费下载OpenEBS 是 Kubernetes 上的云原生容器存储平台其版本发布遵循一套成熟、可复用的流程以月度为节奏组织迭代通过 Release Manager 统筹范围按发布分支 RC 候选镜像 E2E 验证 发布检查清单的路径推进最终以容器镜像与 Helm Chart 形式交付给用户。本文以 contribute/process/release-management.md 为骨架结合仓库内的发布脚本与 Helm Chart 配置完整讲解 OpenEBS 的版本发布机制读者读完后可以掌握其分支命名规则、镜像 Tag 规则、候选发布与 E2E 验证流程以及 Changelog 生成与发布后活动的全套实操方法。版本发布总览月度节奏与角色分工OpenEBS 采用月度发布节奏monthly release cadence。每个版本的范围由两方面决定贡献者的可用性contributor availability待办事项中已列入 ROADMAP 的规划项pending items。实际进入版本的范围会发布在 GitHub 的 Release Tracker Projectsopenebs/projects 下的看板项目中供社区成员跟踪。在每个版本开始之初社区会从贡献者中选定一名Release Manager发布经理与 OpenEBS 项目的一位 Maintainer 结对协作。Release Manager 的职责包括跟踪版本范围tracking the scope与各个相关方stakeholders协调尽早排查并消除版本风险root out the risks as early as possible。Release Manager 借助**每日站会Daily Standup和发布跟踪看板Release Tracker**来保证所有人聚焦在版本目标上。五周里程碑时间轴为了让月度节奏可持续每个版本沉淀出如下五个关键里程碑该节奏是社区在实践中逐步形成的周次核心工作硬性要求第一周完成发布规划为所有目标特性指定 lead第一周末Release Tracker 中不应残留 To do 项若无 lead 认领则将条目推入下一版本 backlog部分贡献者可以继续开发未进入当前版本、但会排入下一版本的条目第二周依据特性成熟度alpha / beta / stable梳理开发、评审、E2E、文档等任务讨论并缓解设计或实现层面的 blocker第三周创建 发布分支产出首批 RC 候选镜像此阶段之后仅接受 bug 修复同时进行升级测试、更新 staging 文档、用新测试自动化 CI 流水线第四周编写 Release Notes将最终 RC 构建推送到 Dogfooding自吃狗粮环境并对部分用户做 beta 测试更新安装器installers发布 Release / Contributor / User 文档第五周发布后活动把新版本同步到合作伙伴 Chart如 Rancher Catalog、Amazon Marketplace 等完成外部渠道的版本分发发布分支Release Branch分支创建时机与命名规则OpenEBS 的组件分散在多个代码仓库中日常活跃开发发生在各仓库的master分支。当某个版本规划的所有开发工作完成或代码冻结期限第三周到来时就从master切出发布分支。分支命名取自版本的主次版本号major.minor例如版本1.10.0对应的发布分支为v1.10.x。发布分支创建之后如果发现需要针对该版本修复的关键问题修复会同时合入master分支**cherry-pick拣选**到对应的发布分支。后续该主次版本的所有打标签操作都从发布分支完成。例如v1.10.0、v1.10.1等补丁版本均基于v1.10.x分支产出。需要创建发布分支的仓库清单发布分支需要在以下仓库中创建openebs/jivaopenebs/libcstoropenebs/cstoropenebs/istgtopenebs/velero-pluginopenebs/cstor-csiopenebs/jiva-operatoropenebs/apiopenebs/cstor-operatorsopenebs/upgradeopenebs/dynamic-localpv-provisioneropenebs/m-exporter使用自定义版本节奏的仓库以下仓库当前采用自定义发布版本不纳入统一的主次版本节奏openebs/node-disk-manageropenebs/zfs-localpvopenebs/lvm-localpvopenebs/rawfile-localpvopenebs/Mayastor从 develop 分支发布的仓库以下仓库处于活跃开发期版本从develop分支发布openebs/linux-utilsopenebs/monitor-pvopenebs/dynamic-nfs-provisioneropenebs/device-localpvopenebs/openebsctlopenebs/monitoring验证发布分支是否创建文档提供了开箱即用的验证脚本。该脚本位于openebs/charts仓库当前仓库通过 Git submodule 管理相关组件子模块分支管理脚本见 scripts/git/set-submodule-branches.sh 与 scripts/git/check-submodule-branches.shgit clone https://github.com/openebs/charts cd charts git checkout gh-pages cd scripts/release ./check-release-branch.sh release-branch从源码结构看当前仓库的 scripts/git/check-submodule-branches.sh 实现了类似的校验逻辑遍历.gitmodules中登记的每个子模块检查子模块当前 HEAD 是否包含在origin/branch远端分支中若某子模块 HEAD 不包含在对应分支内则判定失败并退出非零码。发布打标签Release Tagging镜像 Tag 规则OpenEBS 组件以带版本号的容器镜像形式发布。在仓库上创建发布标签会触发构建build集成测试integration tests推送 Docker 镜像到 docker hub 与 quay.io 容器仓库。GitHub 发布标签的格式取决于该标签是候选版本还是正式版本标签类型GitHub 标签格式容器镜像 Tag去掉前导vRelease Candidatev1.0.0-RC11.0.0-RC1正式 Releasev1.0.01.0.0即容器镜像 Tag 由 GitHub 发布标签去掉开头的v推导而来例如v1.0.0-RC1会产生1.0.0-RC1的镜像。依赖仓库的触发顺序每个仓库都配置了自动化脚本负责把镜像推送到 docker 与 quay 容器仓库。当一个仓库发布后Travis 会继续触发其依赖仓库的发布。完整的发布树release tree如下openebs/linux-utilsopenebs/dynamic-localpv-provisioneropenebs/jivaopenebs/jiva-operatoropenebs/cstoropenebs/libcstoropenebs/m-exporteropenebs/istgtopenebs/cstor-operatorsopenebs/velero-pluginopenebs/cstor-csiopenebs/upgrade并行触发与手动打标签的仓库以下仓库使用与其它组件不同的版本体系因此并行触发不依赖上述触发链openebs/node-disk-manageropenebs/zfs-localpvopenebs/Mayastoropenebs/lvm-localpvopenebs/rawfile-localpv以下仓库处于活跃开发期、尚未纳入发布流程需要按需手动打标签openebs/apiopenebs/monitor-pvopenebs/dynamic-nfs-provisioneropenebs/device-localpvopenebs/openebsctlopenebs/monitoring以下仓库处于**废弃deprecated**状态将手动打标签openebs/mayaopenebs/openebs-k8s-provisioner构建监控与镜像验证发布触发后必须持续监控 Travis 构建过程等 Travis 构建全部通过镜像会推送到 docker hub 与 quay.io通过 docker hub / quay.io 的 Tags 页面核对镜像是否就位检查镜像不得存在严重的安全漏洞critical security vulnerabilities。RC 构建与 E2E 测试每个 minor / major 版本由一个或多个Release CandidateRC构建加一个最终正式发布组成。RC 构建从发布周期的第三周开始产出RC 构建的作用是**冻结范围freeze the scope**并维持发布质量首个 RC 构建之前必须先创建发布分支在验证 RC 构建期间发现的问题修复到master后cherry-pick进发布分支再产出下一个 RC 或正式构建。生成 RC 或正式镜像后需要在 openebs/e2e-tests 仓库发起运行 e2e 流水线的请求通过自动化与人工 e2e 测试启动构建验证。E2E 测试覆盖范围E2E 测试包括以下内容平台验证Platform Verification回归与特性验证自动化测试Regression and Feature Verification Automated testsQA 工程师的探索性测试Exploratory testing对容器镜像执行严格的安全扫描器Strict security scanners从旧版本升级Upgrade from previous releases用户对感兴趣 issue 的 beta 测试Beta testing在 OpenEBS 工作负载与 e2e 基础设施集群上的 Dogfooding自验证当所有测试在 RC 构建上全部通过后才触发最终正式发布构建正式构建上会重复执行一遍 E2E 测试。发布构建的 E2E 状态可以在 openebs/e2e-tests 仓库中带release-checklist标签的 issue 上跟踪。发布构建验证全部完成后Helm Chart 与 Operator YAML 会发布到 openebs/charts 仓库。就当前仓库而言伞形 Helm Chart 的依赖关系可见 charts/Chart.yaml它聚合了 openebs-crds、localpv-provisioner、zfs-localpv、lvm-localpv、rawfile-localpv、mayastor 等子 Chart并通过engines.local.*.enabled/engines.replicated.mayastor.enabled条件控制各引擎的启用状态。发布检查清单Release Checklist正式发布前必须逐项核对E2E 测试在 RC 构建上发现的所有 release blocker 均已解决更新后的安装文档与特性文档已验证Release Notes 已更新包含变更摘要与 changelog确认每个独立仓库的 release 都已更新 commit 与 CHANGELOGopenebs-operator 与 Helm Charts 已发布版本已在 openebs/openebs 仓库上打标签版本已在 slack、分发列表distribution lists与社交媒体上公告。关于第 6 项在 openebs/openebs 仓库打标签仓库根目录的 RELEASE.md 补充说明了伞形仓库自身的发布细节OpenEBS 发布流程包含伞形 Helm Chart 的发布待各子项目发布完毕后将各子 Chart 的版本更新进伞形 Chart对应本仓库 charts/Chart.yaml 中的 dependencies 版本随后针对develop分支创建 release 与标签Chart 发布后即可供最终用户使用。生成 Changelog 与发布摘要各仓库的 commit log 更新对每个独立仓库使用以下命令基于发布分支生成 commit loggit checkout release-branch git log --prettyformat:- %s (%h) (%an) --dateshort --since1 month若该仓库没有变更则填写No changes对于RC 标签commit log 记录自上一个 tag 以来的变更对于正式 Release 标签commit log 记录自上一个 release tag 以来的变更理想情况下等于所有 RC 标签 commit 的总和提交 PR 更新CHANGELOG.md。聚合发布摘要在 openebs/openebs 仓库的 wiki 中创建本次发布的聚合变更摘要aggregate Change Summary在 openebs/openebs 的 Releases 页面创建发布摘要Release Summary突出本次发布亮点。发布后活动Post Release Activities正式发布后需要跟进发布新特性的博客Blogs更新 newsletter 内容举办发布网络研讨会Release Webinar更新博客、文档中的新内容或示例例如在 README 中更新状态或流程变化更新 ChartsHelm stable 及其它合作伙伴 Chart包括 Rancher、OpenShift、IBM ICP Community Charts、Netapp NKS Trusted Charts原 StackPointCloud、AWS Marketplace、OperatorHub 与 DigitalOcean 等渠道。仓库内的发布自动化佐证围绕上述发布流程当前仓库沉淀了一批与版本发布直接相关的脚本与配置可作为落地参考伞形 Chart 版本管理charts/Chart.yaml伞形 Chart 定义。当前仓库状态为version: 4.7.0-develop、appVersion: 4.7.0-develop与各依赖子 Chart如localpv-provisioner: 4.7.0-develop、zfs-localpv: 2.12.0-develop、lvm-localpv: 1.11.0-develop、rawfile-localpv: 0.15.1保持一致同时以annotations.helm.sh/images声明 Chart 引用的全部容器镜像。charts/charts/openebs-crds/Chart.yamlCRD 子 Chart版本与伞形 Chart 保持同步当前为4.7.0-develop。scripts/helm/update-chart-version.sh发布时统一更新伞形 Chart 及各依赖版本支持参数--chart-version、--app-version、--localpv-provisioner-version、--zfs-localpv-version、--lvm-localpv-version、--mayastor-version、--rawfile-localpv-version并提供--dry-run预览将要写入的版本从脚本逻辑看它会把每个版本号的前导v去掉后写入Chart.yaml的.version/.appVersion及各 dependencies 的version字段。scripts/helm/update-version-upon-release.sh正式发布前去除开发期版本中的-prerelease后缀或通过--tag version直接把 Chart 与 appVersion 设置为目标版本自动去掉前导v同时同步更新 openebs-crds 等依赖版本。镜像清单生成与校验scripts/helm/images.sh提供generate/patch/verify三个子命令——generate从 Chart 依赖与模板中收集全部镜像写入 charts/images.txtpatch将 images.txt 的内容回写到 Chart.yaml 的annotations.helm.sh/imagesverify则对比线上集群 Pod 实际使用的镜像与清单是否一致缺失即报错。charts/images.txt当前仓库生成的镜像清单内容与 Chart.yaml 的 annotations 一一对应例如docker.io/openebs/provisioner-localpv:4.7.0-develop、docker.io/openebs/zfs-driver:2.12.0-develop、docker.io/openebs/lvm-driver:1.11.0-develop等可用于核对各组件镜像 Tag 与发布版本的对应关系。scripts/release.sh调用 mayastor 子模块中的公共 release 脚本构建并上传kubectl-openebs二进制与upgrade.job镜像并基于 charts 目录执行 Chart 相关发布步骤佐证了伞形 Chart 随版本一起发布的流程。子模块分支管理scripts/git/set-submodule-branches.sh遍历.gitmodules中的全部子模块统一设置分支支持--branch、--clear、--update并会根据 mayastor 子 Chart 版本如release/x.y或develop自动推导应使用的分支与发布分支 develop 分支双轨发布策略呼应。scripts/git/check-submodule-branches.shCI 中校验每个子模块的 HEAD 是否包含在声明的分支中防止子模块指针漂移可作为发布前的分支一致性检查。小结OpenEBS 的发布管理可以概括为一条清晰的流水线月度节奏规划 → 五周里程碑推进 → 从 master 切出vX.Y.x发布分支 → 打 RC 标签产出候选镜像 → 通过 E2E、升级、安全扫描与 Dogfooding 验证 → 打正式标签 → 生成 Changelog 与发布摘要 → 发布 Chart 与安装器 → 同步合作伙伴渠道。其中发布分支 cherry-pick与RC 候选构建 完整 E2E 验证两套机制是保证月度节奏下版本质量的关键。对于希望在自身项目中复刻该流程的团队可参考本仓库的 scripts/helm 与 scripts/git 下的脚本并结合 charts/Chart.yaml 与 RELEASE.md 理解伞形仓库Umbrella Repository在多方组件发布中的聚合作用。赞分享云原生CLI【免费下载链接】openebsA popular widely deployed Open Source Container Native Storage platform for Stateful Persistent Applications on Kubernetes.项目地址https://gitcode.com/gh_mirrors/op/openebs点击查看免费下载相关推荐Crossplane 发布流程与发布工程月度发布节奏、语义化版本与自动化流水线设计Crossplane 发布流程与发布工程月度发布节奏、语义化版本与自动化流水线设计 本篇技术指南以 Crossplane 项目早期沉淀的发布流程设计文档 d云原生后端Tekton Pipelines 发布机制完全指南版本节奏、LTS 支持策略与自动化发布流水线解析Tekton Pipelines 发布机制完全指南版本节奏、LTS 支持策略与自动化发布流水线解析 Tekton Pipelines 是一个云原生 CI/CD云原生CI/CDDevOps后端kOps 版本策略与发布节奏全解支持矩阵、Kubernetes 版本兼容与发布流程kOps 版本策略与发布节奏全解支持矩阵、Kubernetes 版本兼容与发布流程 本文聚焦 Kubernetes OperationskOps项目的版本云原生集群管理运维IaC上一篇终极指南如何用Sorry Cypress实现多项目测试结果统一监控下一篇Classic-Shell 项目常见问题解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考