37 lines
3.6 KiB
Markdown
37 lines
3.6 KiB
Markdown
|
||
# 开发模式
|
||
|
||
常见的Git分支模式:
|
||
- TBD（主干开发模式）
|
||
- Git-Flow模式
|
||
- Github-Flow模式
|
||
- Gitlab-Flow模式
|
||
|
||
## TBD
|
||
为了保证主干代码的质量，避免出现工程师合入到主干的代码break掉主干的情况，Google 采取了以下实践：
|
||
- 代码合入事件触发通过持续集成，确保合入到主干的代码经过充分且必要测试；
|
||
- 通过 Bazel 实现相关代码（指依赖变更代码的代码）的精准测试；
|
||
- **至少 2 个合资格的 reviewer （代码评审人）的 LGTM（Look Good To Me），才允许代码合入主干；**
|
||
|
||
腾讯某 BG 在 2018 年开始的“930 变革”后，在各试点团队推动主干开发（注：并未全公司普遍采用），具体的举措包括：
|
||
- 以度量牵引：通过对特性分支）的生命期监控和预警，实现非主干分支的生命期缩短，倒逼开发团队采用主干开发；
|
||
- 投大力气统一 BG 内的持续集成工具、开发自动化测试平台；
|
||
- 制定了 7 大编程语言的编码规范，并自研代码静态扫描工具；
|
||
- 并参考 Google 推行代码可读性（Readability）、可测试性（Testability）认证制度；
|
||
- 强力推行 CR （代码评审）制度，确保代码的可读性（命名、代码风格、设计、复杂度）。
|
||
|
||
效果：
|
||
- 质量提升：代码质量从可测量的维度得到明显提升（代码规范率、单元测试覆盖率）；
|
||
- 迭代速度提升：试点团队的迭代周期从 4 周或 2 周提升至 1 周；
|
||
- 代码从“私有”变“公有”：通过代码评审制度，提高了代码可读性，使代码从个人拥有（只有写代码的人能看懂），变成团队拥有（整个团队都能看懂）；这一点对于企业非常重要，接手过别人代码的程序们都有感受；
|
||
- 代码的自动化测试覆盖率提升明显，为未来的重构构筑了一张安全网；
|
||
|
||
有些中小企业的技术决策者非常认可持续集成 / 持续交付的理念，从而更希望采用主干开发，但对于主干开发的缺点（或说弥补缺点的成本）存在顾虑。对此，我有如下建议：
|
||
- 基础架构要求：可以考虑采用开源软件，如持续集成采用 Jenkins、Travis CI、Gitlab CI 等，通过简单部署可以投入使用；同时配合代码静态分析工具（如 SonarQube、CheckStyle），确保代码基本质量过关；
|
||
- 自动化测试要求：工具上不存在障碍，现代编程语言（如 java、go、c++）都有内建或第三方的单元测试框架；难点只在于成员的开发习惯，可以通过测试覆盖率工具，以增量覆盖率指标保证新增代码都有完备的自动化测试，从而逐步改变团队的研发文化；
|
||
- 代码评审要求：开源的 Git 服务器（如 Gitlab）基本都支持 push hook，配合开源的 Gerrit 等 CR 工具，可以实现在代码推送（push）或 pull request（合入请求）时触发 1 个代码评审请求，实现评审通过后，代码才正式合入的功能；剩下的就是研发文化问题了，需要在团队内部推行代码规范、代码可读性等宣导和教育工作；
|
||
- 发布时的特性开关：如果要求不高，可以通过代码 hard code 一个常量作为特性开关；如果要求高，也有开源的特性开关（比如：unleash、piranha、flipper）工具可供选择。参考上述建议，并充分认识到主干开发的成本和困难的情况下，中小企业开发团队也并非不可以考虑主干开发的实践。
|
||
|
||
## reference
|
||
- [Google 和腾讯为什么都采用主干开发模式？](https://36kr.com/p/1218375440667012)
|