测试【免费下载链接】protractorE2E test framework for Angular apps项目地址https://gitcode.com/gh_mirrors/pr/protractor点击查看免费下载本文以 Protractor 仓库根目录下的 release.md 发布清单为骨架逐条拆解一次完整版本发布所需的前置检查、依赖升级、文档生成、CHANGELOG 编写、打标签、NPM 发布与官网更新等全部环节。读完本文你将掌握 Protractor 这类框架代码 官网文档 NPM 发布一体化项目在发版时的一套可复用的端到端操作流程并能对照仓库中的 ciFullConf.js、ciSmokeConf.js、generate-docs.sh、.npmignore 等真实文件理解每一步背后的原理。一、发布清单概览与版本号约定Protractor 的发布流程以严格的版本号三连发为锚点假设上一个已发布版本为0.0.J当前要发布的版本为0.0.K下一个将要规划的未来版本为0.0.L。所有操作步骤都围绕这三个版本号展开——既要在0.0.K上收口功能、验证质量、完成发布又要提前为0.0.L建立 Milestone里程碑把未完成的功能项平滑迁移过去避免发版过程中出现功能被遗漏或版本号错乱。发布整体可分为八个阶段本文将逐一深入功能与依赖检查Milestone 收口、Selenium / 浏览器版本核对CI 质量门禁Travis、CircleCI 全绿忽略文件维护.gitignore / .npmignore文档与网站构建验证提前排雷版本号与 CHANGELOG 更新提交、打标签与推送NPM 发布通过 Wombat 代理仓库官网更新、发布后验证与对外宣布二、发布前检查Milestone 收口与浏览器依赖版本核对2.1 管理 Milestone0.0.K 收口0.0.L 开张发布清单的第一条要求发布者先查看0.0.K里程碑下挂载的功能feature与缺陷修复bug fix是否全部合入确认无遗漏后立即为下一个版本0.0.L创建新的 Milestone将0.0.K中确实无法按期完成的条目迁移bump到0.0.L而不是拖延到发布当天再处理。这一步本质上是版本管理的范围冻结scope freeze只有里程碑完全清空才能保证0.0.K的实际内容与 CHANGELOG、NPM 包内容一一对应避免版本号到了但功能没到的尴尬。2.2 核对 Selenium、浏览器驱动与浏览器版本矩阵清单要求发布者在发版前检查是否有新版本的 Selenium / IE Driver、ChromeDriver 或浏览器发布并判断 Protractor 的测试配置是否需要同步更新。Protractor 团队当时的兼容性策略是针对最新两个版本的 Chrome、Firefox 和 IE 进行回归测试。这一策略在仓库的 CI 配置中可以直接找到对应实现Selenium 版本需要同步到spec/ciFullConf.js、spec/ciSmokeConf.js、spec/ciNg2Conf.js三个 CI 配置文件WebDriver 驱动版本需要保证config.json中的webdriverVersions是最新的并本地执行webdriver-manager update拉取最新驱动浏览器版本最新版 Chrome / Firefox 写入spec/ciFullConf.js与spec/ciNg2Conf.js全量测试用其余支持的所有浏览器统一登记在spec/ciSmokeConf.js冒烟测试用。从当前仓库的实际内容看CI 配置中的版本矩阵正是这样分工的。ciFullConf.js面向全量功能测试能力矩阵只保留两个主力浏览器浏览器版本用途配置位置Chrome70全量测试spec/ciFullConf.jsFirefox60全量测试spec/ciFullConf.js而ciSmokeConf.js作为覆盖更多浏览器的冒烟测试套件登记了 Chrome较旧版本、Firefox beta、Safari、Edge、IE 等其余受支持浏览器浏览器版本平台配置位置Chrome55chromedriver 2.27OS X 10.11spec/ciSmokeConf.jsFirefoxbeta—spec/ciSmokeConf.jsSafari9—spec/ciSmokeConf.jsMicrosoftEdge14.14393Windows 10spec/ciSmokeConf.jsInternet Explorer11Windows 8.1spec/ciSmokeConf.jsciNg2Conf.js则复用了ciFullConf.js的能力矩阵仅把 specs 替换为 Angular 2 应用的测试套件// spec/ciNg2Conf.js exports.config require(./ciFullConf.js).config; exports.config.specs require(./angular2Conf.js).config.specs; exports.config.exclude undefined;值得注意的是版本清单里特别提到config.json/webdriverVersions这一配置项但在当前仓库快照中该文件已经不复存在全仓库仅 release.md 一处提及webdriverVersions。结合 package.json 中webdriver-manager: 13.0.0已成为独立 npm 依赖可以推断驱动的版本管理职责已在后续演进中从仓库内嵌的 config.json 迁移到了独立的 webdriver-manager 模块。因此在当前代码库状态下发布者需要关注的是webdriver-manager依赖版本并通过webdriver-manager update更新本地驱动缓存而不是直接修改 config.json——这一历史步骤体现了发布清单与代码库演进之间的差异实际操作时以当时仓库的实际结构为准。三、CI 质量门禁Travis 与 CircleCI 必须全绿发布清单明确要求在打版本号之前Travis 和 CircleCI 两条 CI 流水线都必须通过。这一步是发版的硬性质量门槛任何红测都会阻塞后续的 NPM 发布。3.1 Travis注意 allowed failures 白名单仓库根目录的.travis.yml展示了 Travis 的实际任务划分Node.js 版本矩阵为 9 / 10环境矩阵包含JOBfull全量、JOBsmoke冒烟与JOBbstackBrowserStack三种任务关键点.travis.yml中存在allow_failures配置段把smoke与bstack任务标记为允许失败。清单对此给出的操作要求是发版前必须逐条核对 Travis 上所有失败项确认它们都落在 allow_failures 白名单里——也就是说失败必须是已知且被容忍的而不是悄悄冒出来的新回归。若存在名单之外的失败必须先修复再发版。3.2 CircleCI运行npm testCircleCI 任务运行的是npm test对应 package.json 中的脚本test: node scripts/test.jsscripts/test.js会按顺序执行多组 Protractor 端到端测试例如node built/cli.js spec/plugins/jasminePostTestConf.js等以及通过 jasmine 运行单元测试与依赖测试JASMINE_CONFIG_PATHscripts/unit_test.json、scripts/dependency_test.json。也就是说npm test既是单元测试也是端到端回归是发版前确认代码本身没问题的核心依据。四、忽略文件维护.gitignore 与 .npmignore发布清单要求检查.gitignore与.npmignore是否随仓库新增文件同步更新。Protractor 的两个忽略文件采用共享头部 各自扩展的结构.gitignore 的共享部分排除yarn.lock、chromedriver.log、npm-debug.log、.idea/、.vscode/、selenium/等通用噪音随后追加构建产物与依赖目录built/、spec/built/、node_modules/、website/bower_components/、website/build/、website/docgen/build/.npmignore 同样以共享头部开头但重点在于排除开发期目录与文件debugging/、docs/、lib/、scripts/、spec/、stress/、testapp/、website/、release.md、logo.svg等确保发布到 npm 的包只包含运行时必需的built/产物而不携带源码、测试与文档等体积冗余。这一步的实际意义是发布包干净度直接影响 npm 包体积与安装体验而.npmignore中的release.md恰恰说明这份发布清单本身是维护者工具不应随 npm 包分发给下游用户。五、文档与网站构建验证提前排雷的关键一步清单特别强调在更新 package.json 或 CHANGELOG.md 之前先验证网站与文档生成仍然正常。之所以要提前是因为一旦版本号与 CHANGELOG 被改动后续出错时的排查与回滚成本会显著上升。5.1 用generate-docs.sh对当前提交生成文档清单给出的命令是./scripts/generate-docs.sh HEAD其中HEAD表示针对当前提交而不是尚未存在的 tag生成文档。脚本 scripts/generate-docs.sh 的完整流程可以在仓库中逐步对照参数校验最多接受一个 commit ref 参数工作区洁净检查git status --porcelain非空则直接退出红色提示避免在脏工作区上生成并推送文档确定版本未传参时通过node scripts/get-version.js读取 package.json 的version字段get-version.js 的实现极简——直接输出 package.json 中的版本号这解释了必须提前改版本号再生成文档的原因切换 checkout到对应 tag随后git clean -fxd清理临时文件依赖安装与编译主目录npm install并执行 es5 编译项目提供了npm run compile_to_es5即 gulp 的compile_to_es5任务见 package.json 与 gulpfile.js安装 testapp 与网站依赖npm run install_testapp随后进入website/执行npm install与npm run build发布到 gh-pages删除本地 gh-pages 分支、强制拉取远端 gh-pages、把website/build/*复制到分支根目录并提交chore(website): automatic docs update for version。5.2 为什么必须编译到 es5清单中明确提到We have to compile down to es5 to get dgeni to work必须编译到 es5 才能让 dgeni 正常工作。Protractor 的官网文档由 dgeniwebsite/package.json中的dgeni: ^0.4.1与dgeni-packages驱动从源码 JSDoc 与 markdown 生成 API 文档。由于 dgeni 工具链本身基于较老的 JavaScript 运行时解析逻辑项目需要先把 TypeScript 源码编译为 es5 产物再做文档抽取。generate-docs.sh只能处理部分编译工作清单因此提醒发布者可能需要对代码库/构建基础设施做少量调整例如补齐类型定义或调整注释格式这一步如果拖到版本号已更新之后再处理会因提交内容混乱而变得非常棘手。5.3 网站自身的单元与 e2e 测试文档生成通过后还需要运行网站的单元测试与端到端测试。网站测试代码位于 website/test/unit 与 website/test/e2e其中 e2e 部分如 api_spec.js、navigation_spec.js本身就是用 Protractor 驱动浏览器验证官网各页面渲染与导航行为的自动化用例跑通它们意味着生成出的官网确实是可用的。六、版本号与 CHANGELOG 维护6.1 版本号语义patch 与 minor 的取舍清单规定版本递增规则仅包含缺陷修复bug fixes递增 patch例如0.0.5 - 0.0.6包含任何新功能递增 minor例如0.0.5 - 0.1.0。这与语义化版本SemVer的基本约定一致保证下游用户能仅凭版本号判断升级风险。当前 package.json 中的版本为6.0.0可见仓库演进过程中 minor/patch 语义一直在被遵守。6.2 用 git log 生成 CHANGELOG 素材清单给出了生成规范格式变更列表的命令git log 0.0.J..HEAD --format- ([%h](https://github.com/angular/protractor/commit/%H)) %n%w(100,2,2)%B /tmp/changes.txt该命令对比上一版本 tag0.0.J与HEAD之间的所有提交把每次提交输出为一行- (短哈希)开头、正文缩进换行的格式%w(100,2,2)控制折行宽度与缩进恰好匹配仓库 CHANGELOG.md 中实际使用的条目风格# 6.0.0 ## Breaking changes ... ## Features - ([cf43651](https://github.com/angular/protractor/commit/cf43651...)) chore(debugprint): convert debugprint to TypeScript (#5074)6.3 CHANGELOG 内容筛选原则拿到changes.txt后需要在 CHANGELOG.md 顶部新建一个版本小节并按类型筛选归入featuresfeat新功能提交depsdeps重要依赖的大版本升级fixfix缺陷修复breaking changes破坏性变更单独成节。清单特别强调不需要记录 chore杂务或纯风格改动——CHANGELOG 的首要读者是 Protractor 的使用者而非开发者只保留对升级行为有实际影响的条目。以仓库真实的 6.0.0 CHANGELOG 为例其 breaking changes 一节就清晰列明了Control flow 被移除、改用 async/await、ignoreSynchronization 废弃改用 waitForAngularEnabled、Actions API 变更等会直接影响用户代码的要点。6.4 Breaking changes 的写作规范破坏性变更必须独立成节并为每个变更提供before/after 迁移示例告诉用户旧代码长什么样、应该如何改写。这一步直接决定用户的升级成本是 CHANGELOG 中信息密度最高的部分。6.5 提交信息规范版本号与 CHANGELOG 更新完成后需要一次专门的提交提交信息模板为chore(release): version bump and changelog for 0.0.K即chore(release): version bump and changelog for 0.0.K。该约定式提交Conventional Commits风格与 CHANGELOG 中大量chore(...)/feat(...)前缀的提交保持了一致方便后续自动化工具解析。提交内容仅包含 API 变更与 package.json 的版本修改保持提交聚焦、易回滚。七、打标签与推送发布提交就绪后进入 Git 操作阶段按顺序执行git tag 0.0.K # 在本地为当前提交打上版本标签 git push remote # 推送主分支 git push remote --tags # 推送所有标签随后在远端仓库核对 CHANGELOG 与 tags 是否呈现正常例如标签是否指向正确提交、CHANGELOG 渲染是否缺失条目。这一步是发布前最后一次肉眼检查避免把格式问题带到 npm 包中。八、NPM 发布通过 Wombat 代理仓库Protractor 的 npm 发布并不直接走默认 npm registry而是通过Wombat NPM 代理wombat-dressing-room.appspot.com完成。这一设计在 package.json 中也有体现publishConfig: { registry: https://wombat-dressing-room.appspot.com }清单给出的操作是npm login --registry https://wombat-dressing-room.appspot.com登录成功后执行npm publish。发布前还应注意 package.json 中的prepublish: gulp prepublish钩子其执行链为checkVersion - tsc - built:copy见 gulpfile.js即发布前会自动编译 TypeScript 并复制构建产物确保 npm 包中的mainbuilt/index.js与typingsbuilt/index.d.ts都是最新生成的。九、官网更新与发布后验证npm 发布完成后立即回到官网更新流程运行文档生成./scripts/generate-docs.sh不带参数时脚本会自动读取刚刚更新的 package.json 版本号并 checkout 对应 tag切换到 gh-pages 分支对自动生成的网站更新提交执行git commit --amend修改提交信息随后推送到远端针对已发布的官网运行 e2e 测试确认线上页面正常。这里的git commit --amend用法很典型generate-docs.sh已经用模板提交信息chore(website): automatic docs update for version生成了提交发布者再通过--amend补全信息例如加入具体版本号或补充说明保持官网提交历史的整洁与可追溯。十、对外宣布与里程碑收尾最后两个收尾动作对外宣布由官方账号ProtractorTest在 Twitter 发布版本公告通知社区升级关闭里程碑在 GitHub 上关闭0.0.K里程碑为0.0.L腾出管理空间形成发布即收口的闭环。十一、发布全流程核对清单速查表阶段关键动作仓库内可验证的对应物范围冻结收口 0.0.K 里程碑建 0.0.L迁移未完成项—依赖核对Selenium / ChromeDriver / 浏览器版本更新spec/ciFullConf.js、spec/ciSmokeConf.js、spec/ciNg2Conf.jsCI 门禁Travis 失败全部落在 allow_failuresCircleCInpm test通过scripts/test.js、.travis.yml忽略文件同步 .gitignore / .npmignore.gitignore、.npmignore文档预检./scripts/generate-docs.sh HEAD 网站单测/e2escripts/generate-docs.sh、website/test/e2e版本与日志patch仅 bugfix或 minor含新功能递增git log 生成变更breaking changes 独立成节含 before/afterpackage.json、CHANGELOG.md提交与标签chore(release): version bump and changelog for 0.0.Kgit tag 0.0.Kgit push --tags—NPM 发布Wombat registry 登录并 publishpackage.json 的publishConfig官网更新重新 generate-docsgh-pages 上git commit --amend后推送e2e 验证线上网站scripts/generate-docs.sh收尾Twitter 公告关闭 0.0.K 里程碑—小结Protractor 的发布清单展示了一条对框架型开源项目极具参考价值的发版流水线以里程碑为范围边界以 CI 双通道为质量门禁以文档预检为排雷手段以约定式提交与结构化的 CHANGELOG 为沟通媒介再经由代理仓库完成 npm 分发最后用 gh-pages 更新与线上 e2e 验证完成发布闭环。对想要复用这套流程的维护者而言仓库中 generate-docs.sh、CHANGELOG.md 与三个 CI 配置文件就是最直接的活教材——它们既记录了该做什么也通过脚本与配置的细节回答了为什么这么做。赞分享测试【免费下载链接】protractorE2E test framework for Angular apps项目地址https://gitcode.com/gh_mirrors/pr/protractor点击查看免费下载相关推荐Stylelint 版本发布全流程指南从 Release Issue 到 npm 发布与官网同步Stylelint 版本发布全流程指南从 Release Issue 到 npm 发布与官网同步 本篇技术指南以 Stylelint 仓库维护者文档 docs代码质量静态分析前端OmniRoute 发布检查清单实战指南从版本号变更到 npm 发布的完整发布流程OmniRoute 发布检查清单实战指南从版本号变更到 npm 发布的完整发布流程 导读 本文基于 OmniRoute 官方运维文档 docs/ops/REL后端API网关LLM 网关人工智能大模型MCP 服务桌面应用OmniRoute 发布清单Release Checklist实战指南从版本号提升到 npm OIDC 发布与回滚的完整流程OmniRoute 发布清单Release Checklist实战指南从版本号提升到 npm OIDC 发布与回滚的完整流程 导读 本文基于 OmniRo后端API网关LLM 网关人工智能大模型MCP 服务桌面应用上一篇Winhance中文版开源Windows系统优化工具的终极指南下一篇终极指南如何在Windows上获得苹果触控板的原生级体验创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考