武让，极狐 (GitLab) 高级解决方案架构师
本文依据“寰球互联网架构大会”现场演讲内容整顿，约 6000 字。
1988 年，微软高级主管 Paul Maritz 写过一封题为“Eating our own Dogfood”的邮件，向微软局域网管理工具我的项目的测试主管提出“进步外部应用自家产品比重”的挑战。从那时起，Dogfooding 作为一个专业术语，疾速流传开。
在向消费者推出之前，Dogfooding 容许员工应用并测试他们公司的产品，因而 Dogfooding 能够作为品质测试，它为开发人员提供了在产品公布之前，解决产品相干问题的机会。并且在开发人员应用本人公司产品进行软件开发的过程中，会对他们正在构建的软件有更深的了解，并能切身体会到产品的用户体验如何，这能极大改善创立技术产品的技术专家与产品最终用户脱节的问题。
极狐 GitLab 提供开箱即用的开放式一体化平安 DevOps 平台，该平台笼罩了项目管理、源代码治理、集成、继续交付、平安扫描等诸多性能。极狐 GitLab 正在踊跃实际着 Dogfooding 文化，首先，提倡公司各个岗位的人员都应用这个产品，不论是 HR、销售还是研发团队，在不同场景外面应用，笼罩足够多的性能。其次，咱们应用 GitLab 并且基于 handbook 来进行合作，将内容和流程都积淀成为 handbook，并把它公开出来。
从 DevOps 这个较大的维度来看，极狐 GitLab 的开发人员从四个方面来进行 Dogfooding：
1. 极狐 GitLab 项目管理实际
极狐 GitLab 应用轻量、麻利、issue 驱动的形式来进行项目管理，并应用机器人辅助去做需要治理。
2. 极狐 GitLab 版本控制实际
极狐 GitLab 版本控制最佳实际五步走，高效治理代码，进行合作。
3. 极狐 GitLab 继续交付实际
通过 CI/CD 去集成大量自动化工具帮忙实现测试，在高效率的同时保障产品的高质量和平安。
4. 极狐 GitLab 效力评估实际
极狐 GitLab 具备价值流剖析和效力剖析两项性能，辅助进行效力评估。
极狐 GitLab 项目管理实际
以极狐 GitLab 的研发团队举例来说，下图是它的残缺研发流程：
极狐 GitLab 是月发版制，研发团队的产品迭代周期为一个月，从第一个月的月中到第二个月的月中，一个残缺的产品迭代周期分为四个局部：
- 从第一个月月中到第二个月第一个周一，这期间，团队专一于新版本的性能开发；
- 第二个月的第一个周一到第一个周三，产品经理进行下一个迭代周期的打算，研发人员评估工作量；
- 到了第二个月的周三，团队会开具体的需要讨论会，用来明确需要和打算，并给出明确公示进行评估；
- 第二个月的第三个周一，残缺迭代周期进入了序幕，团队进行复盘，对值得发挥和须要改良的内容进行剖析。
更多详细信息，参见 handbook
产品：
https://GitLab.cn/handbook/pr…
研发：
https://GitLab.cn/handbook/en…
1. 极狐 GitLab 的麻利开发管理体系
那么整个产品迭代我的项目是如何进行治理的呢？极狐 GitLab 反对麻利开发管理体系，它用群组、子群组和我的项目来别离对应我的项目和子项目，通过施行 epic、子 epic 和 issue 来对应原始需要的工作、子工作，这项目管理的第一步。
产品经理创立原始需要后，和研发人员一起细化需要，并基于 invest 准则拆分需要。首先明确所有需要，撰写具体的 user story。撰写实现后，如果大家有其余意见，能够以评论的形式写在该 issue 下，而后进行探讨，直到需要明确。
GitLab 以及 GitHub 这些开源社区或开源产品都是 issue 驱动，即无论是开发的工作、开发的需要还是 bug 缺点，一律都用 issue 进行治理。
2. 标记 Label 辨别 issue 类型
随着组织倒退，issue 会越来越多，咱们如何进行辨别呢？极狐 GitLab 以一种灵便的自定义形式去打上不同的 Label，来辨别不同 issue。
Lable 是多级式的，第一级是一个 type，它决定了该 issue 是一个 bug、性能还是 QA 等。当打上第一级 Label 后，还须要打上第二级甚至第三级，比如说这个 bug 是性能问题、平安问题，还是来自一个手机端等等，能够自在精准地定义 issue。
3. 看板 Board 自定义 issue 视图
有了 Label 辨别还不够，对研发人员来说，须要一个视角去看这些 issue。研发团队能够通过看板的形式进行 issue 治理，看板其实就是不同视角的视图。比如说在极狐外部，研发团队、测试团队还有产品团队都有属于本人的看板.
产品团队关怀的是工作的调配，所以有一张以研发工程师为视角的看板，比方张三在做需要 A，李四在做需要 B，这些都有一张看板；此外还有一张工作流看板，展现需要进行到什么阶段。对于测试人员来说，只须要看到相干 bug，不须要管在做什么，当然也可能会看一下看板，能够依据不同团队的职责进行划分。
4. 机器人 Triage 主动解决 issue/MR
Triage 机器人也是个十分乏味，有价值的性能。如果用户不分明 issue 的提交形式，会导致 issue 治理艰难。举个例子，当用户提交 issue 后，没有调配人员来跟进，那它就被搁置了；或者用户不分明该打上什么样的标记，是 bug 还是性能，导致 issue 分类凌乱。
应用 triage 机器人能够轻松解决这些问题。当用户提交了一个 issue 后，他不晓得该进行什么操作，就把 issue 敞开了，这个行为被机器人捕捉到，它会立刻在这个 issue 下增加一条评论，并且发邮件告知创建人应该打上 type。当用户打上 type 后，机器人又会随机从测试人员中抉择一位，把他加到这个 issue 的指派人里，跟进这个 issue。通过这种形式能够很好地把 issue 治理起来。
5. 里程碑 Milestone 迭代布局与回顾
在我的项目之初和实现之后，能够应用里程碑来对我的项目进行布局和回顾。以下图极狐 GitLab 15.1 的燃尽图为例：
这个燃尽图并不是现实的燃尽图，因为它并不贴合参考线。在整个迭代周期的第一周，研发人员开始解决需要的时候，会发现有些需要形容得不是很分明，导致评估内容减少，或者说有一些新的需要会引进来，所以这个曲线在第一周的时候甚至有点上扬。
前两周集中进行开发，这时并没有开始大规模测试，所以曲线比拟平缓。两周后，次要性能都实现测试，开始染指大规模测试，这时又会发现一些 bug，所以曲线又有一些向上的稳定。两三周之后，这个曲线开始急剧下降。
GitLab 版本控制最佳实际五步走
版本控制即如何治理代码，代码如何合作，极狐 GitLab 对于版本控制总结出了五步走的最佳实际。
1. 抉择分支策略
在这一步并不是让大家去应用支流分支策略的某一种，而是应该在企业外部制订一套对立的、适宜本人的分支策略。只有分支策略对立之后，研发流程和治理才容易做到对立。
下图是极狐 GitLab 的分支模型，以 master 骨干分支为主。如果要做新性能，或开发新需要，须要创立对应的性能分支 feature，而后基于 feature 分支来做开发。开发实现没有问题之后，必须通过评审的形式把它合并到主分支里，这是一个残缺的流程。举个例子，如果咱们要修复一个 bug，须要创立 bug fix 的分支，而后再通过评审合并进主分支。
如果所有的性能都做得比较稳定，邻近发版的时候，再从 master 分支里再抽出一个版本分支 stable，比如说当初要发 15.0，那就抽一个 15.0 的 stable 分支进去。然而并不是所有的版本肯定都能够始终用上来，封版之后难免会有一些问题。
当须要做一些热修复 hotfix 来修复安全漏洞时，还是走 bug fix 分支策略，再通过 cherry pick 的形式把它从 master 分支抽出去。比如说修复了破绽，就把提交的这部分代码 cherry pick 到 15.0 的 stable 分支里，打上 Label。一开始是 15.0.0，修复了一个版本之后，就变成了 15.0.1，再往后依此类推。15.0 stable 这个分支相当于已独立，不会再往 master 合并。
2. 基于分支开发
倡议大家基于一个新的分支进行开发，不要间接在主分支下开发，这样做长处体现在两方面。
第一是便于协同。举个例子，如果说当初要做一个新的性能，多位开发人员都在同一个分支里去进行开发，此时分支没有隔离，大家同时提交代码，导致他人的工作没方法进行。
第二是便于审核。当每个研发人员都基于一个新的分支进行开发后，想要合并进主分支，则每个研发人员提交的代码都能在评审后合并入主分支，能很好地控制代码品质和代码平安危险。
3. 小步快跑提交
写了代码之后，研发人员肯定要尽快提交，防止电脑或磁盘损坏导致代码失落。另外，当一口气提交了太多代码时，如果咱们要做一些回退，让一些性能选择性上线，则无奈实现此操作，因为从大量提交的代码里不能很好地辨认哪些代码对应哪些性能。
4. 形容提交信息
GitLab 是一个开源我的项目，任何人都能够奉献代码，然而须要标准治理。比方极狐 GitLab 分支命名有肯定规定，它可能以版本号结尾，或以 feature 结尾全都是小写，只容许应用中划线、下划线，不容许应用其余距离字符。
对于代码提交也是同样的，代码提交 commit message 须要大写结尾，必须清晰地描写出你要做什么事，还要带上对应 issue 编号，因为这样能力把需要和代码关联起来，这是一些具体的要求。
极狐 GitLab 有个性能是推送规定，能够通过正则表达式的形式进行束缚和校验，能保障社区贡献者也依照这个规定来进行开发。
5. 定期代码评审
最初一步也是最重要的一步就是代码评审，做好代码评审能力充分发挥版本控制、基于分支开发最次要的价值。益处很显著，但大家也晓得，劣势就是要花费大量工夫去做代码评审，且收益可能并不是那么显著，所以很多企业就疏忽掉这一步了。
那该如何去做代码评审呢？
首先会在整个的合并申请外面去关联，这一次代码的合并解决什么问题，实现什么需要，须要与后面的 issue 对应关联起来。
其次是谁来做代码评审。GitLab 每一个功能模块都有绝对应的研发负责人，咱们能够叫他 code owner，这个关系是提前建设好的，在不同文件夹里对应好。一旦提交代码影响到这些不同文件夹的代码，就会有相应人员会参加到评审中。整个过程是主动的，不须要手动去调配。
最初，尽量应用自动化测试工具，比方代码品质扫描、平安扫描、性能测试、单元测试等，都能通过自动化的形式联合 CI/CD 实现，并且后果能返回到代码评审里，自动化测试工具最次要的价值和意义就是帮忙咱们实现评审。
比方单元测试率肯定要达到多少，代码品质肯定要达到什么级别，能力把该代码合并进去，对于评审人员来说，就不须要再去人工查看命名规不标准，正文写没写全，这些过程全都是自动化的了。通过应用自动化测试工具，评审员更多地做一些抽查工作，极大提高效率。
极狐 GitLab 继续交付实际
1. 极狐 GitLab CI 流水线
极狐 GitLab 外部的 CI/CD 流程跟绝大部分公司没有太大的区别，CI 负责打包编译，而后 CD 负责公布。
然而具体细节，比如说在 CI 除了要解决代码构建的问题外，还要实现品质扫描、平安扫描和单元测试，并把测试报告集成进来。这些性能都是极狐 GitLab 自带的，并会尽可能把这些性能用在实践中。
尽管某些性能在上线初期并不那么弱小，但还是须要继续应用，一方面能够通过实际验证这些性能是否失常，从而不断完善它。另一方面，通过这些性能来保障公布进来的产品质量和平安。
2. 单元测试
单元测试在做什么？其实就是根本次要性能的单元级别的测试用例自动化。其中重点是两个数据，第一个是测试用例的通过率必须是 100%。如果单元测试都没有通过，那肯定存在问题，无奈被合并。第二个要看的数据覆盖率，即外围代码笼罩到单元测试的比例，这个数据必须达到 90% 能力被合并。
3. 品质扫描
定义代码品质有这几个指标：变量的命名是否标准，正文是否齐全，整个代码格调是否合乎该语法的最佳实际，还有兼容性、复杂性、重复性各个方面，从这些指标来对整个代码进行全面的品质扫描。
极狐 GitLab 对本人产品的品质要求是，所有重大问题肯定要解决，次要级别问题或次要以下级别问题能够选择性解决。对于次要级别问题举例来说，在一个函数外面，条件判断不应该超过四个，超过就认为这个函数略简单，或者说这个函数的代码超过 50 行也认为简单。这其实是规定定义的问题，规定是存在肯定灵活性的，如果认为没有必要去聚焦拆分函数，而是实现它的性能，那么便于浏览就能够了，并非齐全要严格执行这样的规定。
4. 平安扫描
极狐 GitLab 将 7 种不同类型的平安扫描的工具集成到了一起，每一次代码提交都能够应用这些平安能力笼罩一遍，包含动静测试、动态测试、密钥检测、依赖项检测等等。
扫描出的重大级别和高级别的安全漏洞，肯定要庄重看待，并且要全副解决。此外，因为用到了十分多动态测试，而动态测试容易呈现误报，因而有些误报的数据须要研发人员去进行评论，给出意见，相干审核人员确认后，把它标记为疏忽就能够了。
5. 在合并申请中应用 GitLab CI
应用了这么多自动化测试工具，最初还是要把测试后果返回到代码的合并申请里，帮忙进行代码评审，这才是最重要的一点，但整个 CI 过程跟代码评审其实存在一些问题。
举个例子，如果要在合并之前执行流水线，那么流水线执行在哪？执行在原分支，原分支即性能分支，首先须要确保新加的性能在新分支上是否编译通过，如果新分支的 CI 都无奈通过，合并后必定会有问题。
但即使在原分支下 CI 能通过，也并不代表它合并到指标分支之后也能通过，因为主分支如 master 分支一直有新代码合上来，无奈保障本次合并之后，会不会跟骨干分支的代码有抵触或潜在烦扰，一旦合并后呈现问题，那该主分支就无奈应用，因而这里存在一些问题和危险。
罕用的解决办法是在一次 CI job 里，本地模仿这个代码曾经合并，而不是在 GitLab 代码仓中，在 server 级别去合并。实际形式很简略，用 git 命令后，fetch 再加 git merge 命令，就能够实现整个代码的模仿合并，之后再去运行流水线，这意味着实现了预测将来的能力。一旦流水线通过后，代码再合并入指标分支，呈现抵触的危险会升高。
另一种形式，对于极狐 GitLab 来说，曾经把它做成了产品化的性能，叫合并后果流水线，开启它就能够实现相似成果，极狐 GitLab 每一次代码评审都是基于合并后果流水线去实现的。
6. 极狐 GitLab CD 流水线 for 自部署（Delivery）
CD 中的 D 代表两种不同的意义，一个是 delivery，一个是 deploy。Delivery 就是打包，实现交付。GitLab 主打的是私有化部署，所以大多以安装包的形式交付给客户和用户，在这样一个场景里，更多的就是面向不同操作系统进行打包，打出不同的版本镜像来。
7. 极狐 GitLab CD 流水线 for SaaS（Deploy）
第二个 D 是 deploy，极狐 GitLab SaaS 产品分成两种不同环境，一个是 staging 环境，即预览环境；还有一个是真正的应用环境——production 环境。无论是哪种环境，咱们都采纳金丝雀公布的策略，即有三套正本，这三套正本里有一套是 canary，另两个是主版本。如果应用 GitLab 的 SaaS，能够在左上角看到一个 next 标记，点击之后就会切换到 canary 正本。
对于 staging 环境来说，发版策略是每天发三次，六点、十二点和下午四点会主动公布。而对于生产环境来说是每周两次，并且是须要人工参加的，这个影响比拟大，须要人员进行把控。因为 GitLab 这个我的项目容量体积差不多有 500 个 G，所以整个 CI/CD 流程须要一个多小时，部署实现后，会主动发到研发人员聊天工具进行揭示。
上图右下局部 Release Tools Bot 处有早上 8:13 的一条告诉，这阐明是第二次构建，并且前一次失败了。六点钟开始构建一个多小时的工夫，到七点钟可能构建失败了，而后又构建到八点钟。此外，每一次发版都要把这个版本跟具体的合并申请关联起来，即每一次发版都要有清晰的 release note。
效力评估
1. 价值流剖析
最初是效力上的一些实际，这部分分成三个方面，第一个是价值流图，第二个是 Dora 指标，第三个是代码提交量和代码提交行数的统计。
价值流是对研发中各个环节用时中位数的统计，比如说打算、编码、测试、评审等环节的用时，它会辨认工作流中哪些环节是瓶颈，从而剖析到底是哪个环节的哪一些人和事件出了问题。
其次是 Dora 指标，Dora for K 指标如部署频率、变更前置工夫、复原率、复原工夫、变更失败率，都是行业内比拟通用的指标。对于极狐来说，部署频率是 10.4，意味着每天至多要部署 10 次。而后两个指标是没数据的，因为这是上个月新版本中的性能，这个图是本月初截的，因而还没有数据。
2. 效力剖析
效力剖析其实就是排行榜，但这并不能齐全地掂量一个人的价值。效力某种意义上是能够评估的，然而一个人的价值并不能被齐全量化。
极狐 GitLab 也有一些员工评优的形式，比如说极狐 GitLab 是月发版，因而每个月都会评比这个月的 MVP，即对该月版本奉献最大的同学，这个 MVP 并非通过代码量去评判，而是从产品层面来看做的性能是否有价值。
此外更多是评估研发人员跟其余共事、外围团队，在沟通交流、代码评审各环节合作过程中，对员工的感触、态度、积极性、为人处事等方面进行考查。也就是说一部分做量化的考核，一部分还是以非量化的理性形式为主。
分享回顾
首先是 Dogfooding，极狐 GitLab 外部会优先应用本人的产品，当外部有需要想去洽购第三方零碎时，第一工夫要想到本人的产品能不能做这个事，如果能够，就推广到全员去应用，无论是后勤、销售还是研发。这能够帮忙发现问题，不断改进产品。
Dogfooding 另一个重要的价值就是能够帮忙咱们去做翻新。举个例子，在极狐外部，用 GitLab 治理 OKR，跟客户交流信息也全副记录在 GitLab。能够一直挖掘产品性能，实用于不同场景中。
其次是项目管理，极狐 GitLab 应用轻量、麻利、issue 驱动的形式来进行项目管理，并应用机器人辅助去做需要治理。这个大家是能够借鉴的，就是用 webhook 加 API 的形式去帮忙咱们更好进行项目管理。
第三是版本控制五步走的最佳实际。
第四是继续交付 CI/CD，重点是两个方面，第一是咱们通过 CI/CD 去集成大量自动化工具帮咱们实现测试。另一方面以自动化测试为门禁帮忙咱们进行代码评审，在高效率的同时保障产品的高质量和平安。
最初在效力评估局部提到了价值流、Dora 和效力治理。其中最重要的，就是效力某种意义上是能够度量的，然而一个人的价值并不是齐全能够被度量的。