Bitwarden 贡献文档
⮐ Bitwarden Contributing Documentation我的博客联系我
  • 关于
  • 入门
    • 概述
    • 工具
    • 服务器
      • 设置指南
      • 高级服务器设置
      • 数据库
        • MSSQL
        • 实体框架
      • 事件日志
      • Ingress 隧道
      • SCIM
      • 自托管指南
      • 系统管理门户
      • 单点登录 (SSO)
        • 本地 IdP
        • Okta
      • 故障排除
      • 用户机密
      • 公共 API
    • 网页客户端
      • 网页密码库
        • WebAuthn
      • 浏览器端
        • 生物识别解锁
        • Firefox 隐私模式
      • 桌面端
        • Mac App Store Dev
        • Microsoft Store
        • Native Messaging Test Runner
        • 更新测试
      • CLI
      • 故障排除
    • 移动端
      • Android
        • F-Droid
      • iOS
      • .NET MAUI (legacy)
        • Android
        • iOS
        • watchOS
    • SDK
      • 内部 SDK
      • Secrets Manager
        • Integrations
          • Kubernetes
    • 业务 App
      • 目录连接器
        • JumpCloud
        • OpenLDAP Docker 服务器
      • Key Connector
      • Splunk App
  • 贡献
    • 贡献
    • 代码样式
      • =Android & Kotlin
      • Angular & TypeScript
      • C#
      • =Rust
      • T-SQL
      • =Swift
      • Tailwind
    • 数据库迁移
      • 进化数据库设计
    • 提交签名
    • 拉取请求
      • =贡献审查程序
      • 分支
      • 代码审查
      • UI 审查 - Chromatic
    • 无障碍
    • 依赖管理
    • 功能标记
    • 模板存储库
    • 测试
      • =数据库集成测试
      • 负载测试
      • 单元测试
        • 命名约定
        • 测试结构
    • 修改用户机密
  • 架构
    • 架构
    • 架构决策记录 (ADR)
      • 0001 - Angular Reactive Forms
      • 0002 - Public API for modules
      • 0003 - Adopt Observable Data Services for Angular
      • 0004 - Refactor State Service
      • 0005 - Refactor Api Service
      • 0006 - Clients: Use Jest Mocks
      • 0007 - Manifest V3 sync Observables
      • 0008 - Server: Adopt CQRS
      • 0009 - Composition over inheritance
      • 0010 - Angular Modules
      • 0011 - Scalable Angular Clients folder structure
      • 0012 - Angular Filename convention
      • 0013 - Avoid layered folder structure for request/response models
      • 0014 - Adopt Typescript Strict flag
      • 0015 - Short Lived Browser Services
      • 0016 - Move Decryption and Encryption to Views
      • 0017 - Use Swift to build watchOS app
      • 0018 - Feature management
      • 0019 - Adoption of Web Push
      • 0020 - Observability with OpenTelemetry
      • 0021 - Logging to Standard Output
      • =0022 - Authorization
      • =0023 - Identifying Integrated Clients
    • 移动客户端架构
      • =Android
      • =iOS
        • =推送通知故障排除提示
      • =.NET MAUI (legacy)
        • =概述
        • watchOS
    • =SDK 架构
      • =数据模型
      • =依赖
      • Password Manager
        • Web
          • =互操作性
      • =Secrets Manager
      • =服务器绑定
      • =版本控制和破坏性更改
    • 网络客户端架构
      • 概述
      • 数据模型
      • 表示层
        • Angular
        • CLI
      • =依赖注入
      • 服务层
        • Vision
        • 实现
    • 服务器架构
    • 深度剖析
      • 身份验证
        • 双重身份验证
      • =授权
      • =浏览器自动填充
        • 收集页面详细信息
        • 生成并执行填充脚本
        • 表单提交检测
        • Shadow DOM
        • =内联自动填充菜单
      • Captcha
      • =只读数据库副本
      • 事件日志
      • =FIDO2 和通行密钥
        • =凭据
        • =操作
        • =命名惯例
        • =实现
          • =提供程序
            • =浏览器扩展
          • =依赖方
            • =用于解密的通行密钥
        • =术语表
      • 推送通知
        • 移动端推送通知
        • 其他客户端推送通知
      • =SSH 密钥和代理
        • =SSH 代理
      • =状态提供程序框架
        • =派生状态
    • =安全
      • =定义
      • =原则
        • =P01 - 锁定的密码库是安全的
        • =P02 - 半受损设备密码库的有限安全性
        • =P03 - 完全损坏的系统没有安全性
        • =P04 - 控制密码库数据的访问权限
        • =P05 - 将安全漏洞的影响降至最低
      • =要求
由 GitBook 提供支持
在本页
  • 所有权​
  • 团队拥有的存储库​
  • 共享的存储库​
  • PR 示例​
  • 工作流程
  • 审查
  • Jira 票证
  • QA 测试​
  • 回归
  • 关闭无关的 PR
  • 更新配置
  1. 贡献

依赖管理

上一页无障碍下一页功能标记

最后更新于1个月前

对应的

Bitwarden 使用 来自动更新依赖项。Renovate 会每周自动为依赖项创建拉取请求。安全更新会立即生成拉取请求。

所有权​

Bitwarden 的存储库分为两类:团队拥有的和共享的。

团队拥有的存储库​

从依赖性的角度来看,团队拥有的存储库由单个团队「拥有」。指定的团队负责审查、批准和合并依赖项更新。一个存储库可能由团队拥有的一些原因是该存储库主要由该团队开发,或者是为了平衡团队需要管理的依赖项数量。

团队拥有的存储库的一些示例是 (由管理控制台团队拥有)和 (由身份验证团队拥有)。

共享的存储库​

共享存储库没有任何直接拥有者。相反,每个依赖项都分配给一个团队。分配给某个依赖项的团队负责审查、批准和合并该依赖项。对于重大升级,该团队负责与其他团队协调升级。

共享的存储库的示例是 和 。

PR 示例​

工作流程

Renovate 会在周末自动创建拉取请求,这自然与每个团队在下周一分配一些时间来处理各自团队中的拉取请求相吻合。团队应共同努力在一周内解决未完成的拉取请求,以避免工作停滞。

主要的例外是重大升级,有时可能需要更长的时间来协调。理想情况下,团队会提前协调并解决弃用问题。

Renovate PR 可能包含单个依赖项或一组相关依赖项。在 Bitwarden,我们通常会将已知相关且应同时升级的依赖项进行分组。我们尽量使分组尽可能小,以最大程度地减少影响并增加批准和合并的信心。

审查

典型的依赖关系工作流包括以下步骤:

  1. 阅读提议的变更。

  2. 审查当前升级和建议升级之间每个已发布版本的每个依赖项的发行说明。确定是否有影响我们代码的任何弃用或破坏性变更。

    • 对于破坏性变更,要么自己解决,要么与其他团队协调解决重大变更。

    • 对于弃用,在受影响团队的积压工作中创建高优先级的 Jira 票证,到期日期至少要比下一个计划的主要依赖项版本早一个冲刺。

  3. 验证 CI 状态。

  4. 如果测试覆盖率不足,请在本地检查并手动确认几个关键区域。

  5. 审查提议的代码变更并批准 PR。

  6. 编写包含 QA 测试说明的 Jira 票证。

  7. 合并 PR。将 Jira 票证分配给 QA。

Jira 票证

开发人员和 QA 之间的交接将通过 Jira 票证进行。该票证应包含受影响的依赖项、要测试部分的任何相关发行说明,以及受影响区域的一些测试说明。

QA 测试​

虽然开发人员负责编写带有测试说明的 Jira 票证,但 QA 工程师应该进行尽职尽责,同时考虑依赖项变更的影响,并在需必要时与工程师讨论可能增加或减少测试范围的问题。

回归

如果 QA 发现了回归,开发人员应负责评估影响并立即还原更新或在新 PR 中解决回归问题。

关闭无关的 PR

有时,由于各种原因,Renovate 会为我们目前无法升级的依赖项创建 PR。例如, contributing-docs 依赖于 docusaurus ,而后者支持特定版本的 react。在 docusaurus 支持它之前,我们无法升级 react。

在这些情况下,团队可以对 PR 注释不升级的原因,然后关闭 PR 或推迟到以后再升级。如果团队关闭了 PR,则希望其成员监控其依赖性,并在未来重新考虑升级问题。

更新配置

{
  "matchPackageNames": ["@angular/core"],
  "description": "Platform owned dependencies",
  "commitMessagePrefix": "[deps] Platform:",
  "reviewers": ["team:team-platform-dev"]
}

对于由单个团队维护的存储库,无需使用 packageRules 来分配所有权。相反,请确保设置了适当的代码所有者。

Renovate PR 包含多个相关领域。上面的 PR 示例包含了两个分组的依赖项。PR 提议将依赖项从 6.0.21 升级到 7.0.12。该版本的存在时间为 13 天,13% 的存储库已采用该版本。Renovate 在 Renovate 管理的存储库中的测试成功率为 74%,以及对这一更改的置信度较低。有关更多详细信息,请参阅。

Renovate 通过每个存储库中的 .github/renovate.json 文件进行配置。为了保持一致性,我们遵循一个内部模板。该模板可在中获取。

Renovate 使用一个名为 的概念,它允许我们指定依赖项的所有权,并确保将适当的团队添加为审查者。下面是将 @angular/core 指派给 Platform 团队的示例。

合并置信度的 Renovate 文档
模板库
PackageRules
官方页面地址
Renovate
directory-connector
key-connector
server
clients
Renovate PR 示例