过去的 2022 年有一个显著的现象是，国内大多数企业少见地拥有了共同的转型策略——降本增效。
这个词向市场传递出一个信号：企业不再寄望于无穷尽的增长以及高投入带来的回报，而是开始学着省着点花钱。
对于某些有“完美产品梦”的软件开发企业而言，他们的方式是试图做出一个完美的产品，实现生产力提升。
然而，业务人才不足、研发流程繁杂以及项目迟迟无法交付的骨感现实告诉他们仅仅拥有工具/产品并不是万能的，仅靠 「完美产品」 并不能帮助企业降低研发成本，提高效率，为经营利润赢得更多增长空间。
就在 2022 年年底，Gitee 团队「阳」了一片，许多小伙伴们都被迫居家办公。短期居家还让打工人欢喜，但长期居家却带来了工作沟通成本、研发效率等问题，甚至还让人精神内耗。
居家期间，我们也发现真正实现提效不能仅靠工具，要想提升生产力离不开人、流程以及工具的相互协作。基于此，去年年底我们策划了一场直播，邀请了 Gitee DevOps 架构师牛万鹏、DevOps 技术负责人徐旭分享了居家办公摆脱精神内耗的切身体会，想要看直播回放的同学可以前往Gitee 视频号查看整期精彩内容。
评论区和后台有小伙伴们对万鹏、徐旭在直播过程中分享的干货意犹未尽，也有人十分好奇 Gitee 提及的研发提效「新十条」有些什么，以及 Gitee 所强调的研发提效的道法术究竟是什么。
现在，为大家揭秘。
研发提效「新十条」
Gitee 重磅发布的工程提效创新十条是什么？
牛万鹏：去年，国家密集颁布了许多疫情防控政策，其中最引人注目的是「新十条」。
我作为我们公司的第一个“小羊人”，直接让整个公司居家办公，相当于一个人干趴了整个公司。
居家办公的时候会引来一个问题，尤其对于作为协作较为紧密的软件开发企业而言，我们既得当面去聊，还要当面去对需求，又要当面去对接口，其中就会涉及到很多的角色沟通，不可避免就会有效率低下的问题出现。
在这种情况下，我们怎么来去延缓效率的下降呢？
在此不谈提高，其实提高效率是很难的事情，我们只能是说怎么去延缓效率下降。于是紧扣时事，Gitee 重磅提出了个“Gitee 研发提效新十条”。
这十条并不是这几天提出来的。从 2020 年疫情之初，Gitee 就已经开始建设一些居家办公相关的能力。我们思考怎么才能延缓效率下降，其中 Gitee Go 本质上也是为了解决我们公司本身内部的问题，然后才慢慢对外发布的。
所以说，Gitee 研发效能创新十条也实践了三年的时间，只不过因为新契机，我们把这些规则与标准汇聚成了下列的十条。
今天，我挑几个和大家展开讲讲。
成就卓越代码质量
首先，第一个也是最重要的就是要提高代码整体质量，成就卓越的代码。
作为一位软件研发工程师最看重的是什么？是代码。
不管是使用瀑布还是敏捷，或者现在的工程效能等等分析研发工程师的效率词汇，最根本的东西还是在代码上。因此不管是在公司的办公场所，还是居家去办公，我们仍要非常重点强调要有卓越的代码质量。那怎么去实践呢？
第一点就是要有严格的 Code Review。有 Code Review 的同时，我们还要通过流水线进行代码提交以及自动化代码规范扫描等等行为。总的来说是帮助开发者更集中关注在研发代码上，而不用去关注后续的发布、部署等等。
那么如何保证代码质量呢？
实际上，一个人的精力是有限的。如果我想在代码上有所成就，得投入大量精力和时间去写代码。而这样的投入不可避免会挤压我们与其他角色进行联调的时间。
因此，为了要让工程师把更多的时间放在代码上，后续需要靠优秀的工具去解决。
减少变更和审核时间
这是我提到的第二点，要减少变更和审核时间。这块怎么做呢？
我认为可以用智能化的方式减少变更和审核时间，通过智能化工具去解决这些问题。
可能有人会问为什么还需要智能化工具？难道不可以让智能机器人直接写代码吗？
至少目前来看，写代码这个事情还看不到任何一个银弹可以用来解决 AI 写代码的问题，即便是之前火爆的 AI 写代码的工具实际上真正应用到业务上是运行不起来的。
所以说代码智能化编写这事，现在还为时过早，但是我们可以将做后边的减少变更审核时间变得智能化。
比如代码提交之后，自动触发代码规范扫描、安全扫描等代码维度的检测；此外通过镜像构建或者测试部署包时，也可以引入类似 API 的自动化测试，甚至还可以有单元测试。同时，接口自动化、压力测试、冒烟测试，如果有条件还可以尝试 UI 自动化测试等等，这些行为都可以通过智能化工具来完成。
所以说我们一定要重视工具。因为这样做能让有开发者有更多的时间放在提升代码整体质量，成就卓越代码上。这是一个相辅相成的过程。
增强测试持续可靠性
同时我认为增强测试可靠性也是研发提效的妙招。
上文提到的内容大都站在一个开发工程师的维度，但在整个研发流程中要想保证效率与质量，不仅得靠开发工程师付出精力，同时也需要重视测试工程师的作用。
值得一提的是，这块大家要厘清一个概念：测试工程师不等同于测试。毕竟不单单是测试工程师要做测试工作，开发工程师也需要做测试的工作。
我们所说的增强测试可靠性实际是指在整个软件研发闭环过程中由于向系统中引入了特定的变化，它允许了开发或测试工程师为变更添加更多相关的正向和反向测试，从而让代码变得更加可靠。
那我们怎么做到增强测试可靠性呢？
我认为可以强制要求研发工程师必须要写单元测试。从理论上来讲，要构思写“好"一条单元测试所花的时间可能要比我们写正常代码的时间还要长。
当然这只是一个局部角度，如果从一个开发工程师宏观角度来说，写单元测试会大大增强代码的健壮性，同时也会大大提高产品质量与交付效率。
从测试的角度而言，我们也可以引入更多的自动化测试工具以及强制性的标准来增强测试可靠性，比如代码的安全扫描工具、部署包的安全扫描工具等等。
降本增效的道法术
企业如何规模化落地 CICD ？
牛万鹏：知其然，更要所以然。想要知道如何规模，首先要明确为何要规模化落地？也就是强调文化的一致性、实践方法一致性以及要有统一的研发流程，总结起来就是道法术。
有序到无序，熵增变熵减
文化就是道，实践就是法，工具就是术，这些所有的事情再抽象一点就是要保证一致性，同时让团队熵减。
这个熵就是我们初中和物理学的那个熵。对于宇宙万物里边一切事物，它默认都是熵增的。
放到我们的研发团队来看，伴随研发团队规模越来越大，人数越来越多，那么不可避免是大家都在熵增。
我们代码是越写越多，代码的逻辑越来越复杂，产品的功能也越来越多。我们不能说它不好用啊，不能说它的功能是累积，是没用的，只不过是这就是一个产品演进，软件研发的必然的生命周期。它就是越来越复杂，它就是一个上升的、从有序变成一个无序的过程。
当引入 CI/CD 流水线、用标准化流程，规模化落地 CI/CD 的时候，本质上是让熵增逐渐变成了熵减，从而保证研发效率不下降，这也就是我们为什么要落地 CI/CD。
那么我们怎么去落地 CI/CD 呢？
其实简单的就一条，保持一条标准线，不要让团队熵增就行了。
比如团队要采用流水线，但是一些人在用 Jekins，一些人是自己搭建的，另外一些人则是。但是现在团队要求统一管理构建环境，要统一管理发布环节，大家都别用其他东西了，统一用 Gitee Go 吧。那么，这种行为很容易引起研发团队的反感。
大家会认为，我目前使用的工具很好，为什么让我迁移呢？
而且企业让我迁移后还有各种各样迁移成本啊，这就不是让团队熵增了吗？
面对这类问题，应该怎么解决呢？
其实从公司的高层来说，他们希望有个统一的工具，有统一的研发文化，有统一的研发实践，因为只有这样才能够整齐划一。
为什么军队的效率这么高？那不就是一个整齐划一的一致性嘛。但是在研发流程中不可能像军队那样军事化管理。毕竟企业最大的活力就是自由、创新，创造。
那么落地 CI/CD 或者 DevOps 时，我们如何平衡呢？
团队需要一个牧羊人
我认为，我们需要一个关键的角色——牧羊人，牧羊人是个什么角色呢？
按照刚才咱们提到的落地 CI/CD 的方法论来看，就是谁来去执行这些东西。这个牧羊人可以是个角色，也可以是一个团队，比如敏捷教练的本质也是一个牧羊人。
因此，团队要有教练这样的角色存在。这个角色不是一个单独的角色。比如我们一个 10 人的研发团队，想去落地 CI/CD ，难道我还要单独招一个牧羊人吗？
当然不是，我们只需要在团队内找一个 master 就好了，由这位 master 进行宣讲，来去带头实践。我们回归到这个牧羊人从道上（研发文化）要做什么东西呢？
实际上，牧羊人在就在研发文化的层面上，要着重去讲我们为什么要从其他各种各样的研发工具迁移到 Gitee Go、云效等等。
它本质是个讲道理的过程，是在告诉我们的研发同学，现在每一个小组都各自维护一套 CI/CD 的工具，代码管理的工具等等，这些行为会给他们自己带来很多的维护成本。刚才我们在讲的"新十条"的时候，我们提到了工程师的时间是非常宝贵的。所以他们应该有创造力，应该更多的是放在企业代码层面上，而不是去维护那些无关紧要的工具。那么 CI/CD 这些工具应该有专门的团队来去维护，去解释清楚不统一工具带来各种各样的运维问题。
对症下药的实践
其次就是对症下药的实践，我们既要有牧羊人，也要根据团队的规模诊脉，给出不同的研发流程。
比如说，一个五人的小团队就没必要做特别复杂的集成流水线，只需要最简单的搭一条流水线，代码提交完，自动的编译构建，如果做的比较精致的话，再加一些单元测试，加一些人工测试的卡位。然后再到发布，到部署测试环境，以及部署测试完毕之后再发布的生产环境，就这样一条简单的流水线就够了。
但是对于更大一点团队来说，团队要负责的服务就多了去了。当系统就多了就可能有前端后端要拆分，还有负责微服务、数据库、service等等外部层面的东西。这时，他们就需要有更复杂的集成流水线去做事情。而这些事件都需要有这个牧羊人从头到尾把它捋出来，帮助研发团队去搭建。靠研发团队自己去建设是不行的，所以必须要有牧羊人的存在。即便研发团队对应的 master 自行搭建或编译脚本时都需要有牧羊人来去帮忙，排查。
其次，工欲善其事，必善利其器。想要落地 CI/CD 就要有统一的工具，要去调研哪些工具是合适的。这些工具要对症下药，要符合团队实践，符合团队的方法论，同时满足团队不同的复杂场景。
总的来说，想要落地 CI/CD 首先得明确我们为什么要做这事，这是为了一致性；其次，为了团队的熵减，需要一个牧羊人讲清楚实践的原因与方法；最后选择一个称手的兵器，能够承载团队的实践场景。
中小企业如何实现 CI/CD 的持续交付？
徐旭：目前，中小型企业一般指的是研发人数在 30 人左右的团队。他们大都处于一个生存期，有的处于发展期。在研发流程过程中，这类企业一般没有专职人员进行管理。因此企业为了要求整个产品迭代速度赶上市场的更新速度，希望去引进一些成熟的产品或方案进行持续交付。也就是说，通过 “小而精”的技术团队去驱动一些大业务、大市场，进而实现团队的快速发展。
那么就会带来两个问题。
第一个问题是：我们的代码要怎么管？
第二个问题是：产品怎么发布？
与此同时，企业并不希望引入复杂的流程和增加额外的人员消耗，又可以解决实际问题并获得效能提升。在此之下，采用 Gitee CI/CD 是一个优秀的解决方案。目前，这类企业在 Gitee 上只需要通过十分钟、两步走就可以拥有成熟的持续交付能力。
十分钟，两步走怎么做？
具体是哪个两步呢？
首先就是用代码托管平台去进行你的代码托管和 PR 评审；其次，用流水线去持续集成和交付。
当然中小企业在持续交付中也会遇到一些挑战。在我看来，主要分为两大点。
第一点就是如果在没有引入成熟的工具或产品的话，这类企业的研发过程会面临下列挑战：
- 团队没有统一的研发流程；
- 管理工具没有约束，研发流程规范基本上是靠研发同学的自觉性；
- 日常发布流程人工干预较多；
- 缺乏一些自动化部署，基本上都是手动，存在问题隐患。
第二点要想满足团队的日常发版的需求，顺利的部署到生产环境，也需要统一化、规范化的管理。具体表现如下：
- 统一的代码托管和评审；
- 构建环境和运行环境保持一致性；
- 规范的自动化发布。
中小企业实践 CI/CD 的解决方案
综上所述，我在这里给出五个步骤或者说解决方案。
第一步就是选择一个平台去开通企业版，在平台里创建一个团队可以共同维护的公共代码仓库；
第二，开发者可以根据任务安排去创建一些特性分支，通过线下编译或者自测提交代码，代码提交自动触发代码扫描，通过发起后合并请求；
第三，根据代码库的一些相关设置，可以给指定的代码评审员发通知，让这个评审员去评审；
第四，然后再进行代码提交，自动触发代码扫描，通过合并请求之后仍然也可以给审核员发发审批；
最后一步是上面的审核完了之后，根据你的发布时间去人工触发流水线，完成构建预发布、发布审核，审核通过部署生产环境这一系列流程，从而实现持续交付。这就是我对于一些中小企业遇到问题的解决方案与策略。
