研发效能实践浅谈

导语

现代的软件行业已经不再是以前“大鱼吃小鱼“的时代了，而是转变成了”快鱼吃慢鱼“的时代。对于很多大型传统软件企业，原本“大“是其优势，现在却陷入了”大船难掉头“的尴尬。对于大量小而美的互联网软件项目，当版本需求被确认之后，比拼的就是研发能力，具体来讲就是从需求转化成软件或者服务的能力，这其中研发效能的高低对于理平台这里首先明确两个关键词的含义：CI: 持续集成，开发提交代码后，自动拉取代码进行扫描检测、自动编译构建产出可以测试制品过程。CD：持续交付，是持续集成的扩展，指的是将通过自动化测试的软件部署到产品生产环境，整个过程没有人为干预。由于开放光网络需求迭代的快速增长，如何做到敏捷开发、持续交付、快速版本迭代变得尤为关键，使项目从需求（PRD）到研发上线全流程真正做到“小步快跑，又稳又快”。

自研上云

其实为何要自研上云，相信每个独立项目方都有各自的理解并且对云化服务的优劣势会有对应的分析，我这里只是为各位看官举个简单的例子（仅代表个人观点）：

更简单的管理（隔离）

过去由传统的 一个大型应用拆分为几十个微服务，分别交由不同的团队开发，不同团队之间水平参差不齐，之后还要你开发的应用服务和其他同学开发的部署到同一台服务器上，结果可想而知；现在我们可以将应用程序的代码、运行环境、依赖库、配置文件等必需的资源打包封装到一个容器里，容器之间达到进程级别的隔离，在容器中的操作，不会影响道宿主机和其他容器，这样就不会出现应用之间相互影响的情形。

更快速的交付和部署（效率）

过去:曾几何时我们和测试之间聊天内容是这样的
开发:"你去测试环境上，按照开发环境一样，再去部署三套一样的测试环境！"
测试:"我....."
几个小时过去了...
测试:"你帮我看看，为什么启动报错，是不是漏配了什么参数?"
开发:"我...."

于是接下来几个小时就这么“愉快的”和测试一起聊天中过去了，严重影响效率

然而，和运维之间聊天一般是这样的

运维:"开发这群脑残，发布的新包，又把生产搞挂了！"
开发:"这帮运维傻叉么，我本地好好的，怎么一上生产就不行了！" ...
于是接下来的几个小时，就在和运维之间的撕逼中过去了!嗯，最终苦的是用户啊！

现在:自从用上docker容器后，可以实现开发、测试和生产环境的统一化和标准化。镜像作为标准的交付件，可在开发、测试和生产环境上以容器来运行，最终实现三套环境上的应用以及运行所依赖内容的完全一致。

在现在微服务的架构中，一个应用拆成几十个微服务，每个微服务都对应有开发、测试、生产三套环境需要搭建。自己算算，如果采用传统的部署方式，有多少环境需要部署。曾听闻某公司在新建一个项目的时候，要花整整一个礼拜来搭建环境，简直是惨不忍睹!

更高的资源利用率（省钱）

Docker 对系统资源的利用率很高，一台主机上可以同时运行数千个 Docker 容器。容器除了运行其中应用外，基本不消耗额外的系统资源，使得应用的性能很高，同时系统的开销尽量小。传统虚拟机方式运行 10个不同的应用就要起 10 个虚拟机，而Docker 只需要启动 10 个隔离的应用即可。 和虚拟机相比，容器仅需要封装应用和应用需要的依赖文件，实现轻量的应用运行环境，且拥有比虚拟机更高的硬件资源利用率，能省多少省多少。

git规则

分支规则

这里使用“分支开发、主干上线”原则，每个代码库，根据目标发布版本， 建立主干版本分支， 主干版本分支的命名规则：feature_YYYYMM__case_id；

代码提交发布规则

谚语曰: ‘Talk Is Cheap, Show Me The Code’，代码，是设计理念落地的地方，是技术的呈现和根本。同学们可以在review过程中做到落地沟通，不再是空对空的讨论，可以在实际问题中产生思考的碰撞，互相学习，大家都掌握团队里积累出来最好的实践方式！当然，如果leader没时间写代码，仅仅是review代码，指出其他同学某些实践方式不好，要给出好的实践的意见，即使没亲手写代码，也是对最佳实践要有很多思考。因此研发提交的每一行code都是需要cr的，并且如何想上线必须经过MR评审通过后合入主干master上线发布。

这里我们设立了预览环境，即云上生产集群的单独建立namespace用于作为代码上线前做各项回归检查的最后一关，预览环境不承载真实流量，不对用户开放入口，只作为研发和测试包括产品经理对上线项目做最后的检查，以保障之后的发布顺利。