轻舟已过万重山——真正的技术派公司是怎么联调、测试和发布的?

郑昀 创建于2017/3/8 最后更新于2017/3/10

关键词:研发协作,Docker,环境变量,开发联调,环境维护,虚拟机,中间件,配置与代码分离,git,jenkins


 

开发联调,测试,预发,生产,稍微上规模的互联网技术团队,每一次发布都需要经历这四个阶段。每一个阶段都对应于一个环境。所以我们会面对:

开发联调环境,测试环境,预发环境,生产环境。

 

产品线若干条。并发多个版本。工程无数,有Java,有PHP,有中间件。

说句狠话:没有趁手的利器,生产效率打完对折再打对折,勿谓言之不预也。

 

云纵有 CloudEngine,如我的私有云的难处—为什么需要CloudEngine?》和《#研发解决方案#研发协作平台CloudEngine文章所述,我以为能非常流畅地打通这四个环境,即使生产环境是混合云,即使应用可能发布在Docker容器里也可能发布在虚拟机里。

 

陈皓同学在从Gitlab误删除数据库想到的中说道:

一个公司的运维能力的强弱和你上线上环境敲命令是有关的,你越是喜欢上线敲命令,你的运维能力就越弱,越是通过自动化来处理问题,你的运维能力就越强。

 

而我希望的是:

环境维护,应用部署,只是勾勾点点,没有心理负担,dont make me think

一个代码分支,对应的一个包(或镜像,对应于 Docker 的 Image),可以流经开发联调环境、测试环境,直接上预发环境,上生产环境,上云端,一路穿行没有障碍,全程无需手工干预,无需手工改配置文件重新打包。

 

这么思考问题的原因也很简单,我们笃信工程师文化,靠技术而不是管理解决问题,正如陈皓同学所言:

如果你是一个技术公司,你就会更多的相信技术而不是管理。相信技术会用技术来解决问题。相信管理,那就只会由制度、流程和价值观来解决问题。

 

那么怎么办到呢?

先来一个管中窥豹:

图0 管中窥豹,CE里是怎么申请服务器资源的

 

再来品尝一下关键点。

 

一,用工具管好配置

之前说过

要做到真正的大环境一致,必须将配置完全与代码分离,这里的配置不仅仅是服务之间的 IP 地址/内部域名/自动发现,还包括不同环境下不同应用的配置参数等。

首先我们把与环境相关的参数都存储在持久化配置中心里,比如 redis/zk 的访问域名,比如第三方合作伙伴的接口IP地址等。

其次,每个应用也都有自己的配置模板,不同环境部署的应用默认继承配置模板,我们可以通过 CloudEngine 对配置做一些微调,也就是下面要讲到的“临时属性信息”了。

CloudEngine 和 SimpleWay 会把环境标识(如 dev/dev-stable/test/test-stable/product 等)和需求工单号,以环境变量的方式打入“服务器”(即容器或虚拟机)里。

工程通过环境变量确认自己在哪一个环境里,对应哪一个需求工单,从而从持久化配置中心读取到当前环境和当前需求对应的属性信息。

 

所谓属性信息有三类:

1)环境属性信息:

环境的配置信息在环境层级设置,对应于“环境管理”菜单。比如开发稳定环境下的环境变量,我可以通过如下界面统一配置:

(图1 环境属性信息)

 

2)应用属性信息:

应用的配置信息在应用层级设置,对应于“应用管理”菜单。比如janus工程(Java)的应用配置,我可以通过如下界面来配置:

(图2 应用属性信息)

 

3)临时属性信息:

应用实例的配置信息在服务器层级设置,对应于“服务器管理”菜单。也就是这次我申请机器资源时,可以通过如下界面设置好临时属性信息,只有这个应用实例能访问到:

(图3 临时属性信息)

 

二,区分出稳定环境和非稳定环境

以前没有 CloudEngine 的时候,我们会维护三套测试环境:常规分支测试环境,紧急分支测试环境,特殊分支测试环境。分别对应于上线的班车模式(每周固定发车),警车模式(bugfix),专车模式(版本很大,开发和测试周期较长)。

维护三套测试环境,真心累。

 

现在只需要维护一套测试环境。

那么问题来了,多个需求工单,怎么在一套环境里并行测试?

秘诀就是,在环境里再建一个稳定环境(Stable)。

 

稳定环境里的应用,只会部署 Release 版本。

根据需求工单申请的新服务器资源,可以访问稳定环境里的业务中心,至少能保证相关业务能正常运行,不会说突然功能不能用了,突然服务宕机了。

 

三,外网请求如何路由

如果开发联调环境和测试环境里的应用需要接受外网的请求,那么在 CloudEngine 里也不需要反复申请外网域名。统一使用 router.yourcompany.com 域名接受外网请求,然后通过 nginx 转发请求到相应的内网应用。

图4 是否需要接受外网请求

 

四,与git紧密结合

在相应的环境里,申请服务器资源时,你不需要键入 git 的代码分支,你输入应用名称,选好应用之后,系统会自动列出相应的分支,智能吧:

图5 分支自动展现

这充分体现了我们的哲学:dont make me think

 

五,小结

我们技术团队可以标准化输出的成体系的通用技术能力有:

1)

基于虚拟机集群和容器集群的研发协作平台:

申请服务器资源(虚拟机或容器),自动化构建,自动化部署,可自动发布到我们自己的公司机房、阿里云、蚂蚁金融云和IDC机房,支持版本回滚;

2)

电商全套中间件解决方案:

  1. 定时任务管理与调度平台,

  2. 异步消息可靠推送系统,

  3. 分布式并行计算调度和管理系统,

  4. 一站式智能监控报警平台,

  5. 分布式跟踪系统,

  6. 分布式缓存管理系统,

  7. 数据库自动化运维平台,

3)

大数据全套解决方案:

  1. 自助式报表平台,

  2. 即席查询系统,

  3. 数据库变更订阅中心,

  4. 实时数据大屏发布平台,

  5. 大数据计算任务发布管理平台,

4)

运维基础设施:

  1. 运维自动化平台,

  2. 云平台基础(虚拟机集群和容器集群),

  3. 大数据分析栈架构。

此体系绝非一朝一夕所能搭建,这是秉承着平凡人做非凡事的理念,一群信仰技术的工程师边开飞机边换引擎,花了几年岁月建造的森严有序的技术体系。

-EOF-

 

欢迎长按二维码订阅我的微信订阅号『老兵笔记』

 

注1:

头图来自于 http://huaban.com/boards/34529674/ 绵羊修道士的练笔之作。

 

注2:

张勇曰:

Joe有一次我们对于海外资本市场业绩发布会上讲过一句话,我觉得还是挺有意思的。

他说,we  work  for  now,we  invest  for  tomorrow,we  incubate for  future(我们为今天工作,为未来投资,为未来孵化一些东西)。最后一句比较特别,为未来冒出来的一二十个小芽里,有一个芽发了,那就大发了,完全变成一个新的未来的主力业务。

 

注3:

前阵子听某公司技术负责人讲他们的工程师文化,我总结了一下:

1、不养闲人,选择能“在一起”的人。

2、进人慢,出人快,该淘汰就淘汰。

3、追求技术巅峰,鼓励内部分享。

4、技术上任何人可以挑战任何人,你行你就上。

5、不做技术/语言之争,只看效果。

6、讨论阶段民主,执行阶段专制。

——tombkeeper

 

注4:

从事任何技术研究,不知道该干什么的时候,就问自己四个问题:

•这个方向上最新进展是什么? 都知道吗?

•这个方向上最著名的专家有哪些?他们的研究都看过吗?

•这个方向上最著名的技术社区有哪些?精华帖都看过一遍吗?

•这个方向上最重要的文章、工具有哪些?文章都看过吗?工具都分析过吗?

——tombkeeper

 

-OVER-

posted @ 2017-03-11 09:58  旁观者  阅读(4398)  评论(1编辑  收藏  举报