YARP 反向代理仓库运维操作手册分支管理、版本发布、补丁回流与依赖流Operations Playbook【免费下载链接】reverse-proxyA toolkit for developing high-performance HTTP reverse proxy applications.项目地址: https://gitcode.com/GitHub_Trending/re/reverse-proxy本篇技术指南以 docs/operations 目录下的运维操作文档为核心系统讲解 YARPReverse Proxy仓库在日常维护中最关键的四大流程分支创建与命名Branching、预览版/正式版发布Release、补丁向后移植到预览分支Backporting以及基于 Arcade/Maestro 的跨仓库依赖流Dependency Flow。阅读本文后你将掌握 YARP 维护者如何从main分支切出release/*分支、如何用 Azure DevOps 流水线把构建产物发布到 NuGet.org、如何处理预览分支上的缺陷修复与内部安全问题以及如何用darc命令行工具管理仓库间的依赖订阅从而能够独立参与或复刻这套开源仓库的运维实践。一、运维文档总览这份 Playbook 覆盖了什么仓库中的 docs/operations/README.md 是整个运维知识库的入口它明确说明本文档主要面向项目维护者maintainers贡献者也可阅读以了解项目流程。整个目录围绕四份文档展开文档主题解决的问题Branching.md分支任务何时、如何从main切出release/*分支以及如何更新main上的品牌版本号Release.md版本发布如何从候选构建一路走到 NuGet.org 正式发布含审批、打 Tag、发布说明与归档BackportingToPreview.md补丁回流预览分支上的缺陷修复如何验证、打 Tag、发布以及内部安全修复的私有流程DependencyFlow.md依赖流如何用 Arcade/Maestro/darc管理 YARP 对 .NET 工程系统Arcade的依赖更新从 eng/Versions.props 可以看到当前仓库版本为3.0.0-preview.1且文件注释明确要求preview与编号之间必须保留一个点如preview.1以保证按 semver 排序时preview.10不会排在preview.1与preview.2之间——这是分支与发布命名背后需要遵守的语义化版本规则。二、分支任务Branching从 main 切出 release 分支2.1 创建发布分支当代码准备进入分支阶段时按以下步骤操作命令均在本地 clone 中执行确保本地main是最新的git checkout main git pull origin main创建发布分支。预览版分支与正式版分支的命名规则不同git checkout -b release/1.1.0-previewX其中X是 YARP 的预览编号。发布非预览版本时分支名应使用release/1.1而不是release/1.1.0——这样分支可以被后续的补丁版本patch复用。若发布的是非预览正式版本还需要在 eng/Versions.props 中将PreReleaseVersionLabel设置为rtwrelease to web即正式版标识运行打包命令build.cmd -pack该命令由仓库根目录的 pack.cmd 间接调用eng\common\Build.ps1 -restore -build -pack完成检查artifacts/packages/Debug/Shipping目录下的包名是否不带后缀例如应为Yarp.ReverseProxy.1.1.0.nupkg而非Yarp.ReverseProxy.1.1.0-dev.nupkg。推送分支到服务器git push origin release/1.1.0-previewX2.2 同步更新 main 上的品牌版本号分支建好后main需要立刻推进到下一个预览编号避免版本回退编辑 eng/Versions.props将PreReleaseVersionLabel改为preview.XX为下一个预览编号提交 PR 并尽快合入文档建议尽量用自动合并。2.3 同步更新 global.json 中的运行时与 SDK在main上检查 global.json 中的tools.runtimes.dotnet与tools.runtimes.aspnetcore确保包含最新的 .NET 8.0当前为8.0.13与 .NET 9.0当前为9.0.2运行时版本SDK 使用11.0.100-preview.6.26359.118。这一步骤保证了新分支的构建环境与 .NET 官方发布节奏保持一致。从源码结构看eng/Versions.props 中的DotNetFinalVersionKind Condition$(PreReleaseVersionLabel) rtwrelease/DotNetFinalVersionKind正是正式版包名不带后缀的底层开关当PreReleaseVersionLabel为rtw时Arcade 将版本定性为最终发布版本。三、版本发布Release从候选构建到 NuGet.orgRelease.md 描述了发布 YARP 预览版的完整指南。正式流程建议先开一个release checklist issue跟踪进度清单包含创建发布分支、更新PreReleaseVersionLabel、在dotnet-yarp-official流水线上定位并验证构建、发布构建、打 Tag、撰写并发布发布说明、关闭旧 milestone、社交媒体公告、保护预览分支、删除上一个预览分支、请求源码归档等步骤。3.1 版本号确认Versioning发布前必须确认 eng/Versions.props 中的版本与预发布标签符合预期正式版发布时PreReleaseVersionLabel必须为rtw。3.2 确保存在发布分支参考 Branching.md 完成三件事创建下一个预览分支更新main上的品牌版本号更新main上的global.json运行时与 SDK 版本。3.3 定位最终构建Identify the Final Build最终构建是 azure-pipelines.yml 定义的dotnet-yarp-official流水线位于 dnceng/internal中在对应release/x分支上的最新一次成功构建。可借助 Azure DevOps 的 Branches 标签页定位。若该分支尚未镜像且无未合入变更也可以使用main分支上对应 commit 的构建。该流水线的构建配置要点可在仓库的 azure-pipelines.yml 中核对触发分支包括main、release/*、internal/release/*在 Windows1es-windows-2022池上执行eng\common\cibuild.cmd -configuration Release -prepareMachine启用真实签名DotNetSignTypereal、SDL 安全扫描policheck、codeql、binskim 等Release 配置下将artifacts/packages/上传为名为artifacts的构建产物。3.4 验证最终构建Validate the Final Build验证方式可根据实际情况选择最低限度是验证示例samples能用候选包运行从构建详情页的 Related 中的 Artifacts 下载最终构建产物NuGet 包位于PackageArtifacts产物中消费 .nupkg 的两种方式Visual Studio把包放入本地文件夹然后在 VS 中将该文件夹添加为 NuGet feed命令行dotnet nuget add source directory -n local按 Getting Started 指南走一遍上手流程并在发布分支上按需更新文档同时验证本次发布涉及的重大新场景及其配套文档。3.5 发布构建Release the build验证完成后进入发布阶段打开dotnet-yarp-release流水线并选择 Run Pipeline在 Resources 中选择已验证产物对应的流水线运行dotnet-yarp-release.yml 中通过resources.pipelines声明了对dotnet-yarp-official的引用反复核对产物中包版本号与验证时一致点击 Run——除非你是发布审批人否则你的工作到此结束。从 dotnet-yarp-release.yml 可以看到发布流水线的实际逻辑PreDeploymentApprovalJob使用ManualValidation1任务向审批人列表karelzmicrosoft.com、samspmicrosoft.com 等发送通知审批通过后NuGetPush任务遍历$(Pipeline.Workspace)\Release\Shipping下的.nupkg只推送以Yarp.ReverseProxy.或Yarp.Telemetry.Consumption.开头的包跳过.symbols.nupkg其余包会跳过并提示update the script to change this。3.6 审批发布Approve the releaseAzure 流水线会向所有发布审批人发送邮件等待其中一人批准点击 Review Manual Validation 或在 Azure DevOps 中直接打开发布流水线会看到阶段处于 Pending Approval输入类似release for preview X的注释并批准批准后包会自动发布此时虽然理论上可以取消流水线但可能为时已晚详见故障排查包被推送后当 NuGet.org 阶段变绿即表示发布成功注意NuGet 发布很快但后台索引可能需要数小时包才会在 NuGet.org 上完全可用。3.7 打 TagTag the commit为最终构建关联的 commit不一定是当前 release 分支的 HEAD创建并推送 git 标签参考以往标签的格式使用轻量标签lightweight tag而非附注标签git tag v1.0.0-previewX git push upstream v1.0.0-previewX注意推送到 upstream上游仓库而不是你的 fork。3.8 发布说明与收尾起草发布说明使用新标签在 GitHub Releases 创建草稿参考以往发布的推荐内容与格式发布发布说明内容应引用最新的文档、包等关闭旧 milestone此时应已清空若还有遗留 issue移到下一个 milestone社交媒体公告发布说明链接发送给 David Fowler其 Twitter 粉丝对 YARP 兴趣浓厚并请其转发保护预览分支避免对预览分支的意外推送或删除删除上一个预览分支此后仓库上应只保留一个预览分支。3.9 源码归档Source Code Archival通过内部 dpsops 门户发起 Source Code Archival 请求按步骤填写表单并等待归档报告核对归档文件大小与数量是否与 YARP 仓库一致。推荐字段值字段值Team AliasdotnetrpBusiness Group NameDevdivProduct NameYARPVersionrelease versionProduction TypedotNETRelease TypeRC or ReleaseOperating System(s)Cross PlatformProduct Language(s)EnglishRelease Daterelease dateFile Countrepo 中大致文件数Back Up TypeCode Repo(Git URL/AzureDevOps)Repo URL内部 AzDo YARP 仓库链接OwnerAliasdotnetrpFile CollectionBuild Scripts, Help Utility Source Code, Source CodeData Size总大小约 MB 数3.10 发布故障排查Troubleshooting认证错误Authentication Errors流水线通过 Azure DevOps 的 Service Connection 认证。若出现认证错误多半是 API Key 失效登录 NuGet.org需microsoft.com账号且有权访问dotnetframework组织生成新 API KeyPackage Owner 选dotnetframeworkPackage glob 填*将新 Key 填入 Azure DevOps 的 nuget.org (dotnetframework organization) Service Connection无权限时联系dncengmicrosoft.com。意外过度发布Accidental OverpublishNuGet.org 设计上不允许删除包只能 unlist从搜索结果中移除。直接引用该版本的下载仍可用但不会再出现在搜索或安装最新版等非版本特定操作中登录 NuGet.org同上权限要求进入包页面点击右侧 Info 侧栏的 Manage package展开 Listing选择误发布的版本取消勾选 List in search results点击 Save。包被拒绝Package was rejectedNuGet.org 对所有Microsoft.开头的包有特殊标准。若因不满足标准被拒参考 NuGet Microsoft 页面了解必备标准与配置指南。四、补丁回流Backporting修复预览分支BackportingToPreview.md 说明把修改回移植backport到预览分支与常规发布的流程非常相似——在预览分支上做修改、验证构建、最终发布。常规步骤# 1. 检出预览分支 git checkout release/1.0.0-previewX # 2. 修改并提交变更 # 3. 推送到自己的 fork并对预览分支发起 PR # 4. PR 合并后等待内部 microsoft-reverse-proxy-official 流水线产出构建 # 5. 按常规发布的验证方式验证构建 # 6. 该构建的 Package Artifacts 可用于验证补丁也可选用公共流水线的产物 # 7. 在预览分支上持续迭代直到验证满意 # 8. 从预览分支发布构建为已发布的提交创建新标签仍在预览分支上时git tag v1.0.0-previewX.build.d git push upstream --tags最后为这个版本创建新的 GitHub Release。4.1 内部修复Internal fixes涉及重大安全或披露问题的缺陷必须先私有修复全部工作在内部 AzDo 仓库完成到披露时再合并到公共 GitHub 仓库单独 clone内部仓库https://dev.azure.com/dnceng/internal/_git/dotnet-yarp避免误推送到公共仓库以上一次发布的 tagged commit为起点创建名为internal/release/{被修补版本}的分支按需更新版本号创建功能分支、修复问题并通过 AzDo 提交 PR从内部分支发布构建打 Tag 并推送到公共仓库——不要推送到内部镜像的常规main或release/*分支按需将变更 cherry-pick 到公共main完成标准发布清单。五、依赖流Dependency FlowArcade、Maestro 与 darc5.1 机制概述YARP 使用 .NET 工程系统 Arcade 构建本仓库。工程系统的一部分是名为Maestro的服务它负责管理仓库之间的依赖流动当某个仓库构建完成后可自动把构建发布到 Maestro 的Channel其他仓库可订阅该 Channel 以接收更新后的构建Maestro 会自动为订阅了依赖变更的仓库打开更新依赖的 PR。本仓库通过 eng/Version.Details.xml 记录了工具链依赖Microsoft.DotNet.Arcade.Sdk与Microsoft.DotNet.Helix.Sdk均来自https://github.com/dotnet/arcade当前版本11.0.0-beta.26407.8对应 commit212960245c74330fbfb71776563638061e35446c而 global.json 中的msbuild-sdks亦引用同一版本——两者共同保证全仓库使用一致的 Arcade SDK。5.2 darc 的安装与基本用法Maestro 可以用darc命令行工具查询与控制。使用前提是加入dotnet/arcade-contribGitHub Team。初始化步骤运行.\eng\common\darc-init.ps1安装全局工具仓库内还提供了对应的 eng/common/darc-init.sh安装后运行darc authenticate并按提示完成认证。不带参数运行darc会显示命令列表darc help [command]查看具体命令的帮助。5.3 查看默认 Channel 映射仓库可基于分支配置为自动把构建发布到某 Channel。查看某仓库的当前映射darc get-default-channels --source-repo [repo][repo]可以是匹配系统内完整 GitHub URL 的任意子串最简便的方式是直接写[owner]/[name]。示例输出 darc get-default-channels --source-repo dotnet/aspnetcore (3796) https://github.com/dotnet/aspnetcore release/6.0 - .NET 6 (5027) https://github.com/dotnet/aspnetcore release/8.0 - .NET 8 (5731) https://github.com/dotnet/aspnetcore release/9.0 - .NET 9 (5732) https://github.com/dotnet/aspnetcore main - .NET 10 (6050) https://github.com/dotnet/aspnetcore release/10.0-preview1 - .NET 10 Preview 15.4 管理订阅Subscriptions订阅通过get-subscriptions、add-subscription、update-subscription命令管理darc get-subscription查看系统内所有订阅用--source-repo [repo]与--target-repo [repo]过滤。例如查看dotnet/yarp订阅了哪些源 darc get-subscriptions --target-repo dotnet/yarp https://github.com/dotnet/arcade (.NET Eng - Latest) https://github.com/dotnet/yarp (main) - Id: 1751e896-c0f1-4247-3909-08d8c8762e9e - Update Frequency: EveryWeek - Enabled: True - Batchable: False ... https://github.com/dotnet/arcade (.NET Eng - Latest) https://github.com/dotnet/yarp (release/2.2) - Id: ebd75d9f-8988-4f50-bd1d-83dfc79fb7ba - Update Frequency: EveryWeek - ...可见 YARP 的main与release/2.2分支都以EveryWeek的频率订阅 Arcade 的.NET Eng - LatestChannel。新增订阅不带参数运行darc add-subscription会打开一个包含 TODO 脚本的编辑器Channel: required Source Repository URL: required Target Repository URL: required Target Branch: required Update Frequency: none, everyDay, everyBuild, twiceDaily, everyWeek Batchable: False Merge Policies: []填充示例Channel: .NET Eng - Latest Source Repository URL: https://github.com/dotnet/arcade Target Repository URL: https://github.com/dotnet/yarp Target Branch: release/42 Update Frequency: EveryWeek Batchable: False Merge Policies: - Name: Standard保存并退出编辑器即创建订阅。编辑已有订阅darc update-subscription --id [ID][ID]从get-subscriptions获取会打开同样的 TODO 脚本但预填当前值修改后保存退出即可。5.5 分支就绪后的依赖流配置前置条件已正确配置darc全局工具并执行过darc authenticate。当 YARP 准备切新分支时先按 Branching.md 完成初始分支步骤YARP 每周都会通过 darc 消费最新 Arcade bits需要为新分支配置依赖流运行darc add-subscription在打开的模板中填写Channel.NET Eng - LatestSource Repository URLhttps://github.com/dotnet/arcadeTarget Repository URLhttps://github.com/dotnet/yarpTarget Branchrelease/XX为 YARP 发布版本号Update FrequencyEveryWeekMerge Policies为多行值Merge Policies: - Name: Standard Properties: {}保存并关闭编辑器窗口。此后Arcade 每次发布新构建到.NET Eng - LatestChannelMaestro 便会自动为release/X分支打开依赖更新 PRYARP 得以每周跟进 .NET 工程系统的最新修复与功能。六、流程串联一次完整发布的端到端视图将上述四份文档串联起来可以勾勒出 YARP 一个版本从分支到落地的完整生命周期分支阶段Branching.md从main切出release/1.1.0-previewX正式版用release/1.1把 eng/Versions.props 的PreReleaseVersionLabel设为preview.X或rtw同时推进main的版本号并更新 global.json 的运行时/SDK依赖流就绪DependencyFlow.md用darc add-subscription为新分支订阅 Arcade 的.NET Eng - LatestChannel让每周依赖更新自动流入构建与验证Release.md在 azure-pipelines.yml 定义的dotnet-yarp-official流水线上定位release/x分支的最新成功构建下载PackageArtifacts进行示例验证发布与审批运行 dotnet-yarp-release.yml 定义的发布流水线经审批人批准后自动推送Yarp.ReverseProxy.*与Yarp.Telemetry.Consumption.*包到 NuGet.org随后打轻量 Tag、发布发布说明、关闭 milestone持续维护预览分支上的缺陷走 BackportingToPreview.md 的 PR→验证→发布→打 Tag 流程安全敏感问题则先走内部internal/release/*私有修复披露时再合并回公共仓库收尾保护当前预览分支、删除上一个预览分支并通过内部门户完成源码归档。这套运维体系与 YARP 的工程结构紧密咬合包名规则Yarp.ReverseProxy、Yarp.Telemetry.Consumption对应 src/ReverseProxy/Yarp.ReverseProxy.csproj 与 src/TelemetryConsumption/Yarp.Telemetry.Consumption.csproj 两个核心项目分支命名中的rtw/preview.X规则则直接由 eng/Versions.props 的版本属性驱动。理解这套流程也就理解了开源 .NET 项目如何在持续演进与稳定发布之间取得平衡。说明本文所有命令与配置均以当前仓库实际内容为准。其中涉及 Azure DevOps 内部流水线、审批人邮箱与归档门户等仅限微软内部可访问的资源外部贡献者请以公共 GitHub 仓库中的 PR/Issue 流程为准。【免费下载链接】reverse-proxyA toolkit for developing high-performance HTTP reverse proxy applications.项目地址: https://gitcode.com/GitHub_Trending/re/reverse-proxy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
YARP 反向代理仓库运维操作手册：分支管理、版本发布、补丁回流与依赖流（Operations Playbook）
YARP 反向代理仓库运维操作手册分支管理、版本发布、补丁回流与依赖流Operations Playbook【免费下载链接】reverse-proxyA toolkit for developing high-performance HTTP reverse proxy applications.项目地址: https://gitcode.com/GitHub_Trending/re/reverse-proxy本篇技术指南以 docs/operations 目录下的运维操作文档为核心系统讲解 YARPReverse Proxy仓库在日常维护中最关键的四大流程分支创建与命名Branching、预览版/正式版发布Release、补丁向后移植到预览分支Backporting以及基于 Arcade/Maestro 的跨仓库依赖流Dependency Flow。阅读本文后你将掌握 YARP 维护者如何从main分支切出release/*分支、如何用 Azure DevOps 流水线把构建产物发布到 NuGet.org、如何处理预览分支上的缺陷修复与内部安全问题以及如何用darc命令行工具管理仓库间的依赖订阅从而能够独立参与或复刻这套开源仓库的运维实践。一、运维文档总览这份 Playbook 覆盖了什么仓库中的 docs/operations/README.md 是整个运维知识库的入口它明确说明本文档主要面向项目维护者maintainers贡献者也可阅读以了解项目流程。整个目录围绕四份文档展开文档主题解决的问题Branching.md分支任务何时、如何从main切出release/*分支以及如何更新main上的品牌版本号Release.md版本发布如何从候选构建一路走到 NuGet.org 正式发布含审批、打 Tag、发布说明与归档BackportingToPreview.md补丁回流预览分支上的缺陷修复如何验证、打 Tag、发布以及内部安全修复的私有流程DependencyFlow.md依赖流如何用 Arcade/Maestro/darc管理 YARP 对 .NET 工程系统Arcade的依赖更新从 eng/Versions.props 可以看到当前仓库版本为3.0.0-preview.1且文件注释明确要求preview与编号之间必须保留一个点如preview.1以保证按 semver 排序时preview.10不会排在preview.1与preview.2之间——这是分支与发布命名背后需要遵守的语义化版本规则。二、分支任务Branching从 main 切出 release 分支2.1 创建发布分支当代码准备进入分支阶段时按以下步骤操作命令均在本地 clone 中执行确保本地main是最新的git checkout main git pull origin main创建发布分支。预览版分支与正式版分支的命名规则不同git checkout -b release/1.1.0-previewX其中X是 YARP 的预览编号。发布非预览版本时分支名应使用release/1.1而不是release/1.1.0——这样分支可以被后续的补丁版本patch复用。若发布的是非预览正式版本还需要在 eng/Versions.props 中将PreReleaseVersionLabel设置为rtwrelease to web即正式版标识运行打包命令build.cmd -pack该命令由仓库根目录的 pack.cmd 间接调用eng\common\Build.ps1 -restore -build -pack完成检查artifacts/packages/Debug/Shipping目录下的包名是否不带后缀例如应为Yarp.ReverseProxy.1.1.0.nupkg而非Yarp.ReverseProxy.1.1.0-dev.nupkg。推送分支到服务器git push origin release/1.1.0-previewX2.2 同步更新 main 上的品牌版本号分支建好后main需要立刻推进到下一个预览编号避免版本回退编辑 eng/Versions.props将PreReleaseVersionLabel改为preview.XX为下一个预览编号提交 PR 并尽快合入文档建议尽量用自动合并。2.3 同步更新 global.json 中的运行时与 SDK在main上检查 global.json 中的tools.runtimes.dotnet与tools.runtimes.aspnetcore确保包含最新的 .NET 8.0当前为8.0.13与 .NET 9.0当前为9.0.2运行时版本SDK 使用11.0.100-preview.6.26359.118。这一步骤保证了新分支的构建环境与 .NET 官方发布节奏保持一致。从源码结构看eng/Versions.props 中的DotNetFinalVersionKind Condition$(PreReleaseVersionLabel) rtwrelease/DotNetFinalVersionKind正是正式版包名不带后缀的底层开关当PreReleaseVersionLabel为rtw时Arcade 将版本定性为最终发布版本。三、版本发布Release从候选构建到 NuGet.orgRelease.md 描述了发布 YARP 预览版的完整指南。正式流程建议先开一个release checklist issue跟踪进度清单包含创建发布分支、更新PreReleaseVersionLabel、在dotnet-yarp-official流水线上定位并验证构建、发布构建、打 Tag、撰写并发布发布说明、关闭旧 milestone、社交媒体公告、保护预览分支、删除上一个预览分支、请求源码归档等步骤。3.1 版本号确认Versioning发布前必须确认 eng/Versions.props 中的版本与预发布标签符合预期正式版发布时PreReleaseVersionLabel必须为rtw。3.2 确保存在发布分支参考 Branching.md 完成三件事创建下一个预览分支更新main上的品牌版本号更新main上的global.json运行时与 SDK 版本。3.3 定位最终构建Identify the Final Build最终构建是 azure-pipelines.yml 定义的dotnet-yarp-official流水线位于 dnceng/internal中在对应release/x分支上的最新一次成功构建。可借助 Azure DevOps 的 Branches 标签页定位。若该分支尚未镜像且无未合入变更也可以使用main分支上对应 commit 的构建。该流水线的构建配置要点可在仓库的 azure-pipelines.yml 中核对触发分支包括main、release/*、internal/release/*在 Windows1es-windows-2022池上执行eng\common\cibuild.cmd -configuration Release -prepareMachine启用真实签名DotNetSignTypereal、SDL 安全扫描policheck、codeql、binskim 等Release 配置下将artifacts/packages/上传为名为artifacts的构建产物。3.4 验证最终构建Validate the Final Build验证方式可根据实际情况选择最低限度是验证示例samples能用候选包运行从构建详情页的 Related 中的 Artifacts 下载最终构建产物NuGet 包位于PackageArtifacts产物中消费 .nupkg 的两种方式Visual Studio把包放入本地文件夹然后在 VS 中将该文件夹添加为 NuGet feed命令行dotnet nuget add source directory -n local按 Getting Started 指南走一遍上手流程并在发布分支上按需更新文档同时验证本次发布涉及的重大新场景及其配套文档。3.5 发布构建Release the build验证完成后进入发布阶段打开dotnet-yarp-release流水线并选择 Run Pipeline在 Resources 中选择已验证产物对应的流水线运行dotnet-yarp-release.yml 中通过resources.pipelines声明了对dotnet-yarp-official的引用反复核对产物中包版本号与验证时一致点击 Run——除非你是发布审批人否则你的工作到此结束。从 dotnet-yarp-release.yml 可以看到发布流水线的实际逻辑PreDeploymentApprovalJob使用ManualValidation1任务向审批人列表karelzmicrosoft.com、samspmicrosoft.com 等发送通知审批通过后NuGetPush任务遍历$(Pipeline.Workspace)\Release\Shipping下的.nupkg只推送以Yarp.ReverseProxy.或Yarp.Telemetry.Consumption.开头的包跳过.symbols.nupkg其余包会跳过并提示update the script to change this。3.6 审批发布Approve the releaseAzure 流水线会向所有发布审批人发送邮件等待其中一人批准点击 Review Manual Validation 或在 Azure DevOps 中直接打开发布流水线会看到阶段处于 Pending Approval输入类似release for preview X的注释并批准批准后包会自动发布此时虽然理论上可以取消流水线但可能为时已晚详见故障排查包被推送后当 NuGet.org 阶段变绿即表示发布成功注意NuGet 发布很快但后台索引可能需要数小时包才会在 NuGet.org 上完全可用。3.7 打 TagTag the commit为最终构建关联的 commit不一定是当前 release 分支的 HEAD创建并推送 git 标签参考以往标签的格式使用轻量标签lightweight tag而非附注标签git tag v1.0.0-previewX git push upstream v1.0.0-previewX注意推送到 upstream上游仓库而不是你的 fork。3.8 发布说明与收尾起草发布说明使用新标签在 GitHub Releases 创建草稿参考以往发布的推荐内容与格式发布发布说明内容应引用最新的文档、包等关闭旧 milestone此时应已清空若还有遗留 issue移到下一个 milestone社交媒体公告发布说明链接发送给 David Fowler其 Twitter 粉丝对 YARP 兴趣浓厚并请其转发保护预览分支避免对预览分支的意外推送或删除删除上一个预览分支此后仓库上应只保留一个预览分支。3.9 源码归档Source Code Archival通过内部 dpsops 门户发起 Source Code Archival 请求按步骤填写表单并等待归档报告核对归档文件大小与数量是否与 YARP 仓库一致。推荐字段值字段值Team AliasdotnetrpBusiness Group NameDevdivProduct NameYARPVersionrelease versionProduction TypedotNETRelease TypeRC or ReleaseOperating System(s)Cross PlatformProduct Language(s)EnglishRelease Daterelease dateFile Countrepo 中大致文件数Back Up TypeCode Repo(Git URL/AzureDevOps)Repo URL内部 AzDo YARP 仓库链接OwnerAliasdotnetrpFile CollectionBuild Scripts, Help Utility Source Code, Source CodeData Size总大小约 MB 数3.10 发布故障排查Troubleshooting认证错误Authentication Errors流水线通过 Azure DevOps 的 Service Connection 认证。若出现认证错误多半是 API Key 失效登录 NuGet.org需microsoft.com账号且有权访问dotnetframework组织生成新 API KeyPackage Owner 选dotnetframeworkPackage glob 填*将新 Key 填入 Azure DevOps 的 nuget.org (dotnetframework organization) Service Connection无权限时联系dncengmicrosoft.com。意外过度发布Accidental OverpublishNuGet.org 设计上不允许删除包只能 unlist从搜索结果中移除。直接引用该版本的下载仍可用但不会再出现在搜索或安装最新版等非版本特定操作中登录 NuGet.org同上权限要求进入包页面点击右侧 Info 侧栏的 Manage package展开 Listing选择误发布的版本取消勾选 List in search results点击 Save。包被拒绝Package was rejectedNuGet.org 对所有Microsoft.开头的包有特殊标准。若因不满足标准被拒参考 NuGet Microsoft 页面了解必备标准与配置指南。四、补丁回流Backporting修复预览分支BackportingToPreview.md 说明把修改回移植backport到预览分支与常规发布的流程非常相似——在预览分支上做修改、验证构建、最终发布。常规步骤# 1. 检出预览分支 git checkout release/1.0.0-previewX # 2. 修改并提交变更 # 3. 推送到自己的 fork并对预览分支发起 PR # 4. PR 合并后等待内部 microsoft-reverse-proxy-official 流水线产出构建 # 5. 按常规发布的验证方式验证构建 # 6. 该构建的 Package Artifacts 可用于验证补丁也可选用公共流水线的产物 # 7. 在预览分支上持续迭代直到验证满意 # 8. 从预览分支发布构建为已发布的提交创建新标签仍在预览分支上时git tag v1.0.0-previewX.build.d git push upstream --tags最后为这个版本创建新的 GitHub Release。4.1 内部修复Internal fixes涉及重大安全或披露问题的缺陷必须先私有修复全部工作在内部 AzDo 仓库完成到披露时再合并到公共 GitHub 仓库单独 clone内部仓库https://dev.azure.com/dnceng/internal/_git/dotnet-yarp避免误推送到公共仓库以上一次发布的 tagged commit为起点创建名为internal/release/{被修补版本}的分支按需更新版本号创建功能分支、修复问题并通过 AzDo 提交 PR从内部分支发布构建打 Tag 并推送到公共仓库——不要推送到内部镜像的常规main或release/*分支按需将变更 cherry-pick 到公共main完成标准发布清单。五、依赖流Dependency FlowArcade、Maestro 与 darc5.1 机制概述YARP 使用 .NET 工程系统 Arcade 构建本仓库。工程系统的一部分是名为Maestro的服务它负责管理仓库之间的依赖流动当某个仓库构建完成后可自动把构建发布到 Maestro 的Channel其他仓库可订阅该 Channel 以接收更新后的构建Maestro 会自动为订阅了依赖变更的仓库打开更新依赖的 PR。本仓库通过 eng/Version.Details.xml 记录了工具链依赖Microsoft.DotNet.Arcade.Sdk与Microsoft.DotNet.Helix.Sdk均来自https://github.com/dotnet/arcade当前版本11.0.0-beta.26407.8对应 commit212960245c74330fbfb71776563638061e35446c而 global.json 中的msbuild-sdks亦引用同一版本——两者共同保证全仓库使用一致的 Arcade SDK。5.2 darc 的安装与基本用法Maestro 可以用darc命令行工具查询与控制。使用前提是加入dotnet/arcade-contribGitHub Team。初始化步骤运行.\eng\common\darc-init.ps1安装全局工具仓库内还提供了对应的 eng/common/darc-init.sh安装后运行darc authenticate并按提示完成认证。不带参数运行darc会显示命令列表darc help [command]查看具体命令的帮助。5.3 查看默认 Channel 映射仓库可基于分支配置为自动把构建发布到某 Channel。查看某仓库的当前映射darc get-default-channels --source-repo [repo][repo]可以是匹配系统内完整 GitHub URL 的任意子串最简便的方式是直接写[owner]/[name]。示例输出 darc get-default-channels --source-repo dotnet/aspnetcore (3796) https://github.com/dotnet/aspnetcore release/6.0 - .NET 6 (5027) https://github.com/dotnet/aspnetcore release/8.0 - .NET 8 (5731) https://github.com/dotnet/aspnetcore release/9.0 - .NET 9 (5732) https://github.com/dotnet/aspnetcore main - .NET 10 (6050) https://github.com/dotnet/aspnetcore release/10.0-preview1 - .NET 10 Preview 15.4 管理订阅Subscriptions订阅通过get-subscriptions、add-subscription、update-subscription命令管理darc get-subscription查看系统内所有订阅用--source-repo [repo]与--target-repo [repo]过滤。例如查看dotnet/yarp订阅了哪些源 darc get-subscriptions --target-repo dotnet/yarp https://github.com/dotnet/arcade (.NET Eng - Latest) https://github.com/dotnet/yarp (main) - Id: 1751e896-c0f1-4247-3909-08d8c8762e9e - Update Frequency: EveryWeek - Enabled: True - Batchable: False ... https://github.com/dotnet/arcade (.NET Eng - Latest) https://github.com/dotnet/yarp (release/2.2) - Id: ebd75d9f-8988-4f50-bd1d-83dfc79fb7ba - Update Frequency: EveryWeek - ...可见 YARP 的main与release/2.2分支都以EveryWeek的频率订阅 Arcade 的.NET Eng - LatestChannel。新增订阅不带参数运行darc add-subscription会打开一个包含 TODO 脚本的编辑器Channel: required Source Repository URL: required Target Repository URL: required Target Branch: required Update Frequency: none, everyDay, everyBuild, twiceDaily, everyWeek Batchable: False Merge Policies: []填充示例Channel: .NET Eng - Latest Source Repository URL: https://github.com/dotnet/arcade Target Repository URL: https://github.com/dotnet/yarp Target Branch: release/42 Update Frequency: EveryWeek Batchable: False Merge Policies: - Name: Standard保存并退出编辑器即创建订阅。编辑已有订阅darc update-subscription --id [ID][ID]从get-subscriptions获取会打开同样的 TODO 脚本但预填当前值修改后保存退出即可。5.5 分支就绪后的依赖流配置前置条件已正确配置darc全局工具并执行过darc authenticate。当 YARP 准备切新分支时先按 Branching.md 完成初始分支步骤YARP 每周都会通过 darc 消费最新 Arcade bits需要为新分支配置依赖流运行darc add-subscription在打开的模板中填写Channel.NET Eng - LatestSource Repository URLhttps://github.com/dotnet/arcadeTarget Repository URLhttps://github.com/dotnet/yarpTarget Branchrelease/XX为 YARP 发布版本号Update FrequencyEveryWeekMerge Policies为多行值Merge Policies: - Name: Standard Properties: {}保存并关闭编辑器窗口。此后Arcade 每次发布新构建到.NET Eng - LatestChannelMaestro 便会自动为release/X分支打开依赖更新 PRYARP 得以每周跟进 .NET 工程系统的最新修复与功能。六、流程串联一次完整发布的端到端视图将上述四份文档串联起来可以勾勒出 YARP 一个版本从分支到落地的完整生命周期分支阶段Branching.md从main切出release/1.1.0-previewX正式版用release/1.1把 eng/Versions.props 的PreReleaseVersionLabel设为preview.X或rtw同时推进main的版本号并更新 global.json 的运行时/SDK依赖流就绪DependencyFlow.md用darc add-subscription为新分支订阅 Arcade 的.NET Eng - LatestChannel让每周依赖更新自动流入构建与验证Release.md在 azure-pipelines.yml 定义的dotnet-yarp-official流水线上定位release/x分支的最新成功构建下载PackageArtifacts进行示例验证发布与审批运行 dotnet-yarp-release.yml 定义的发布流水线经审批人批准后自动推送Yarp.ReverseProxy.*与Yarp.Telemetry.Consumption.*包到 NuGet.org随后打轻量 Tag、发布发布说明、关闭 milestone持续维护预览分支上的缺陷走 BackportingToPreview.md 的 PR→验证→发布→打 Tag 流程安全敏感问题则先走内部internal/release/*私有修复披露时再合并回公共仓库收尾保护当前预览分支、删除上一个预览分支并通过内部门户完成源码归档。这套运维体系与 YARP 的工程结构紧密咬合包名规则Yarp.ReverseProxy、Yarp.Telemetry.Consumption对应 src/ReverseProxy/Yarp.ReverseProxy.csproj 与 src/TelemetryConsumption/Yarp.Telemetry.Consumption.csproj 两个核心项目分支命名中的rtw/preview.X规则则直接由 eng/Versions.props 的版本属性驱动。理解这套流程也就理解了开源 .NET 项目如何在持续演进与稳定发布之间取得平衡。说明本文所有命令与配置均以当前仓库实际内容为准。其中涉及 Azure DevOps 内部流水线、审批人邮箱与归档门户等仅限微软内部可访问的资源外部贡献者请以公共 GitHub 仓库中的 PR/Issue 流程为准。【免费下载链接】reverse-proxyA toolkit for developing high-performance HTTP reverse proxy applications.项目地址: https://gitcode.com/GitHub_Trending/re/reverse-proxy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
