LOADING

Follow me

开篇不谈无线路由,先从DevOps聊起【zoues.com】
五月 6, 2017|DockerPaaS

开篇不谈无线路由,先从DevOps聊起【zoues.com】

开篇不谈无线路由,先从DevOps聊起【zoues.com】

一个玩路由器玩 NAS 的,第一篇不讲无线路由,不讲NAS(网络附加存储),偏偏开篇讲DevOps?!搞笑呢? 

对!先搞笑,再不搞笑就太搞笑了.

讲DevOps 因为和做路由器有很大关系,早期开发时就使用 Trac平台 [1],当时我还不知道这个概念,如果早知道,就会让当时购买我路由器的用户有更好的软件体验,所以计划写个路由+NAS系列,希望朋友们了解下 RTNAS 曾经走过的路,希望自己的经验能帮助到后面的人.无奈本人文笔奇差,很多词不达意,各位看官见谅.

言归正传,

什么是 DevOps? 如下图所示:

开篇不谈无线路由,先从DevOps聊起 [2]

图很清晰,Dev和QA大家都知道,单说 Operations(运维),这一项很多同学不够熟悉,是因为学校不教什么Linux,并且大部分公司很少去安排程序员做运维相关事情.  这里的运维指的不单单是安装个 Linux 以及 Tomcat 等服务,而是能融会贯通整个业务环境,知晓如何 CI ( 持续集成)以及 CD (持续部署).

回想2011年,做DDNAS(无线路由器项目名称)时使用一款叫 Trac 的开源项目管理工具,只用到 Wiki 和 Issue(ticket)管理 以及结合 svn 做代码浏览,开发过程就是提交代码,觉得应该测试了,然后自己去编译出固件,然后人工刷机和测试下,没有实现自动化.大部分时间都是浪费在等待编译以及测试上面,苦不堪言….随着 RTNAS 队伍的扩大,这种情况更加明显…

2013,我去了上海入职了盛大旗下的魔锤网络去做无线路由,CEO黄冬(现任芒果TV CTO)嫌我手工编译代码很土鳖,于是他带领大家实现了编译自动化,测试半自动化.但由于产品没卖上量及各种原因,就没精力去实现 CI,CD了…[3]

2016年年中,我结识了几个大牛并加入了他们的团队,入职了一个纯技术团队,第一天,某大牛扔给我两本书,分别是《高效团队开发与方法》和《Docker:容器与容器云》,大牛喝着维他命水且斜着眼说:赶紧看,以后DevOps的事情就交给你了! 然后过了几天,另一大牛来教我如何使用 GitLab 以及开发注意事项

读这两本书和接受大牛们的教育让我茅塞顿开,意识到我之前的软件项目开发知识都是土的不要不要的….(这2位大牛分别’号称’菊花厂18级和阿里 P8,另外几个大牛分别’号称’菊花厂17级、20级,不想被爆名字的,赶紧现在就用 Android 客户端打赏我几百块:-)


开篇不谈无线路由,先从DevOps聊起


说说主角GitLab,这是一个功能强大的现代化软件开发平台,好用的功能都集成到这个平台中,代码管理,Issues,用户角色,Wiki,Todo,里程碑,可视化查看 CI、CD 进程…各种功能和先进的理念都在 GitLab 中存在…(你可能发现我忽略了 Git 特性:)

我们熟知的开发流程基本都如下图所示:

开篇不谈无线路由,先从DevOps聊起

正常情况下,软硬件开发流程都基本是这个样子, 而DevOps不但要求开发人员编写代码,还要把 编译、测试、部署一系列流程串起来.

CI、CD 过程如下:

开篇不谈无线路由,先从DevOps聊起

CI (Continuous integration):

集成就是 代码集中一处,对编译环境做统一部署,编译程序,然后测试.

持续的集成就是 CI(就是根据需要,不断的 Build、Test).

CD (continuous delivery) 

持续交付

在持续集成的基础上,能持续不断的自动化部署到生产环境上.

那么根据实际情来说CI:

开发每次提交代码并不会触发自动编译,而是根据特定情况来触发Build,比如只有从 develop分支 merge 到release分支时并且带上特定commit 描述才会 Build,然后把编译好的固件 scp 到设备上进行升级(这个过程是 CD,咦和 Web 服务不同? :),再结合测试用例进行黑盒测试得到 pass or fail的结果.

来看看 GitLab 的 CI过程(以路由器举例):

1 当开发从 develop 分支 merge 到 release 分支时触发了编译(GitLab 预先设定好了)

2 如果编译通过,会把程序 scp 到 路由器中,然后 执行刷机.

3 刷机完成会触发测试脚本进行测试.

4 完成测试报告并可以通过 Web 查看.

注:* 下图中展示的Build 机器是 Windows(当然也可以 linux或者 Mac OS) ,需要用安装一个 GitLab-runner 服务在 Windows 上.

下图示例不包含 scp 、自动刷机部分以及测试环境部署.

Build 触发:

开篇不谈无线路由,先从DevOps聊起

编写 CI 文本:

开篇不谈无线路由,先从DevOps聊起

编译过的任务在下图中有显示:

开篇不谈无线路由,先从DevOps聊起

点进去可以看到编译过程:

开篇不谈无线路由,先从DevOps聊起

测试用例报表:

‘曾经,我开玩笑的对编写测试用例的同事说:测试工作就是喝咖啡看报表啊~答:喝咖啡前要吐血到死…’

开篇不谈无线路由,先从DevOps聊起[4]

以上路由器的例子是比较粗的,虽然没有数据库构建和数据加载、环境配置文件这种偏向 Web 服务的展示,更没有出现Docker 这种部署神器(实际上 GitLab-runner 有 Docker模式) 但是依然能体会到 CI、CD 的魅力: 让我们更加集中精力的去完善产品,比如写测试用例和修复 bug,而不是傻傻的等待编译信息刷屏..(编译 Android 的同学应该更深有体会吧..)

在逼呼上,有人说个人项目没必要搞 CI:

开篇不谈无线路由,先从DevOps聊起

不完全同意,就是因为一个人精力实在是有限,所以只有通过自动化才能省心省力,就是通过平台写脚本而已…..而几个人的开发团队,就更要好好规划如何 CI、CD 了,几百人的?不知道,没待过这么大的团队.

DevOps方面我是一个没怎么上过战场的新手,我也不是一个程序员.只是以往的经验告诉我,曾经可以做的更好,曾经可以让队友们有更多的时间来完善产品和多陪陪家人、朋友.

这是开篇,算是挖个大坑…

坑如下:

1 2010年作为一个硬件白痴,如何做出一款无线路由器? DDNAS V1诞生历史到底有多青涩(or不堪回首)?我将诠释什么是无知者无畏 🙁

2 DDNAS V2 是如何改名叫 RTNAS V2的? 为何玩无线路由器的人做了一款纯 NAS?  听说过黑群辉吗?  V1、 V2是黑 QNAP, RTNAS V3是黑群你信不信?

3 无线路由器到底有多难搞? 那么多互联网公司都折戟沉沙? 略略有话说.

4 路由器行业和 NAS 行业还有的玩吗? 

八卦信息:

(2011年期间,怎么做的路由器,做硬件期间经历了那些?软件上开发的成果那些是引以为豪的?为什么一开始叫 DDNAS,后来叫 RTNAS?一开始这个’团伙’有多少人,后来又是如何壮大的?他们是那些精英组成?后来这个团伙的 2500W 估值是什么情况?真金白银花了100多W 后,为啥 RTNAS 团队又不玩了? )

最后,自己在预览的时候发现我的订阅号叫 略略的什么路由值得买.

好吧,我会有空写写哪些无线路由器值得买….

注解和参考资料

[1] https://trac.edgewall.org/  前几年很多开源软件使用 Trac 平台

[2] https://zh.wikipedia.org/wiki/DevOps

[3] 老黄是我见过最优秀的 CTO,感谢老黄给我很多学习的机会.

[4] 路由器自动化测试用例报表.

no comments
Share

发表评论