直播预约通道开启!2021腾讯数字生态大会邀您共探产业发展新机遇! 了解详情
写点什么

我们实施 DevOps 的挑战之三 —— 先流水线?还是工具化?

2020 年 4 月 15 日

我们实施DevOps的挑战之三 —— 先流水线?还是工具化?

从去年 11 月以来,基本上都在写一些成长心得与技术管理类的文章,也有不少朋友问我:“你之前写的 DevOps 系列的连载呢?晃点我们喽?” 如果说这是晃点,还不如说是纠结更合适,因为 DevOps 这东西并不是一天两天的体力活,它更类似 ‘搭积木’ 这样的细致活,在这个过程中充满不确定,节奏中有前进、有倒退。


这种纠结,会导致原本顺理成章的事情在短时间内中断,作为一直倡导落地总结性原创输出的我,与其急急忙忙,还不如 “让采坑多一点” 再写出来。


本系列的两个月轮空,请允许我啰嗦一下,下面继续唠 DevOps。


前两篇,我谈到在「敏捷文化」与「配置中心」的实施过程中所遇到的挑战,并基于实际场景与背景的前提下是如何应对的。其实,自好买提出持续集成、持续交付、持续部署以来,以上两个问题就从来不是核心问题,原因很简单:


文化:慢慢培养,培养不到想要的境界,就坦然面对去接受;

配置:纯技术问题,更容易解决,狠一狠心就行了;


那么,核心问题是什么呢?


对于应用研发来说,如果有一个平台,能够提供项目协作和持续交付两大功能,并将交付形成从需求到反馈的完整闭环,最终提供流水线式的一站式平台,那该是件多么美好的事情。


可是,梦想终究是梦想,现实终究是现实,如果平台提供者每天都在憧憬着梦想,那么当下的痛点又有谁来解决呢?


01 为什么流水线的落地如此困难?


好,先看下我们最初设想的美好蓝图:利用自动化手段,将标准化落地。


这张图展示的是一个常见的新增应用研发过程,我们先在版本管理系统中注册完相关信息,再从「配管系统」中将 master 拉出开发分支进行开发,通过「配置系统」提交相关应用配置信息,然后在「测试系统」中利用自动化测试手段完成测试,最终合并成 release 分支,提交至「部署系统」完成发布。


为了规范操作,提高协作效率,避免错误,我们需要一套平台话流水线来承载这一切。


以上这个看似没毛病的故事,在落地的过程中却遇到了一些困难,主要表现为 “平台使用者” 的出发点与 “平台提供者” 不一致:


1.收益周期:有限的资源必须优先保障业务实现,有多余的资源满足技术改进,每次投入都应该立即有收益,如果连续投入都看不到效果,那我不干;

2.效率优先:用一堆工具就能搞定,界不界面,流不流程不重要,无法容忍建设性等待,能用就行。

3.资源成本:用了这个平台如何才能让我人肉化变为自动化?如果用了你的平台,我还需额外支出更多成本,那我情愿自己来。

4.依赖路径:随着测试与运维进入 FeatureTeam 之后,平台化逐渐失去原有的需求来源,而 FeatureTeam 更愿意自己当即解决痛点,而不依赖于其他团队。


对于大部分金融类企业,「效率至上,结果导向」都是基本原则,在遇到这么多困难时,我们开始思考,在推动流水线一站式平台之前,我们还能做什么?


02 用工具化提升效率,再来谈流水线

其实,如果可以用一堆工具就能解决的事情,非要搞个平台,整一堆界面才能实现的东西,在落地过程中先天就具有劣势。


好吧,我们暂时忘记那张美好的蓝图,通过某个系统的试点,通过工具化的方式,先把持续集成玩透,让使用者快速获得收益。


  • 某系统的痛点与需求(持续集成)

  • 1.测试活动各环节是独立运行的,无法充分利用夜间空闲时间,不便于为研发提供快速反馈的服务。

  • 2.因系统依赖性强,测试环境需部署多系统,但部署耗时长,部署环境容易出现遗漏,造数据难度高。

  • 3.接口测试需手工替换环境上的 dubbo 包,增加测试环境准备时长,上线包不等于测试包。



(第一阶段)


  • 第一阶段:某系统的工具化解决方案(持续集成):

  • 直接使用 Jenkins 组装 CI 场景

  • 通过 Jenkins 脚本,实现数据初始化、构建、部署、调用自动化测试脚本(Python)

  • 在核心接口中,手工编写两套 APP,一套用于 Mock,一套用于正式;

  • 配置更新继续停留在手工阶段;



(第二阶段)


  • 第二阶段:某系统的流水线解决方案(持续集成):

  • 提供 CI 流水线,并支持 Mock 功能:


1.通过 Jenkins 脚本,数据初始化;

2.部署系统(自研): 构建、部署;

3.自动化测试与流程(自研): CI 流水线,mock 测试;

4.服务治理功能(自研): 基于 Dubbo 支持动态路由功能,满足 Mock 场景服务;

5.资源系统(自研):?(暂时没想透)

6.配置系统(自研):?(暂时没想透)


当然,无论从哪个视角来看,这个方案已不像 DevOps 了,只是简单的用「Jenkins+自动化脚本+自研工具」解决一些人肉化的工作罢了。不过这个没关系,至少通过这样的方式,我们可以在一个月内提升效率,释放资源。


用未来的视角展望一下,最终是否完成那张美好的蓝图,又有谁关心呢?毕竟,系统也好,平台也罢,是给人用的,不是用来装 B 的。


今天咱就唠到这吧,下回咱们来谈谈 —— 在 DevOps 中,那些高度集中的基础服务。


本文转载自头哥侃码公众号。


原文链接:https://mp.weixin.qq.com/s/VhiuYIG9DBTLq6oekKF7cg


2020 年 4 月 15 日 16:43227

评论

发布
暂无评论
发现更多内容

极客大学架构师训练营 框架开发 上课总结 第五课

John(易筋)

极客时间 设计模式 极客大学 极客大学架构师训练营 框架开发

架构师训练营第三周课后作业

赵凯

设计模式

架构师训练营 - Task Week 3

brave heart

极客大学架构师训练营

蟒周刊/426: DjangoCon US 2020 取消了

ZoomQuiet大妈

Python 大妈 蟒营® Weekly 蟒周刊

2020互联网公司端午节礼盒合集!你最中意哪一款?

Java小咖秀

互联网人 端午节

【架构思维 - 学习总结】week03

chun1123

学习 设计模式

【第三周】命题作业——单例及组合模式

三尾鱼

极客大学架构师训练营

【架构师训练营 - week3 -1】作业

早睡早起

【架构师训练营 - week3 -2】总结

早睡早起

手写单例模式

yupi

让你眼前一亮的 10 大 TS 项目

阿宝哥

Java typescript Web 前端开发 开源项目

设计模式-第三周

X﹏X

windows使用docker运行mysql等工具(一)windows安装docker

Java旅途

MySQL Docker

极客大学架构师训练营 框架开发 第三次作业

John(易筋)

极客时间 设计模式 极客大学 极客大学架构师训练营 框架开发

可读代码编写炸鸡二(下篇) - 命名的歧义

多选参数

代码 代码优化 代码组织 代码规范

架构师训练营 0 期第三周

Blink

架构师训练营-作业3

进击的炮灰

可读代码编写炸鸡二(上篇) - 命名的长度

多选参数

代码 代码组织 代码规范

架构师训练营第三周作业

极客大学架构师训练营

面向对象的设计模式

WW

windows使用docker运行mysql等工具(二)安装运行mysql

Java旅途

MySQL Docker

【架构思维学习】 week03

chun1123

架构师训练营第三周-学习总结

架构师训练营-总结3

进击的炮灰

组合模式应用

yupi

区块链改变数字营销与广告市场

CECBC区块链专委会

区块链技术 广告业 精准投放 去中介 公开透明

小师妹学JVM之:java的字节码byte code简介

程序那些事

Java JVM Java 25 周年 bytecode 字节码

数字货币监管当体现“中国之治”

CECBC区块链专委会

数字货币 CECBC 区块链技术 技术标准 准入和监管

产品失败了,产品经理要不要承担责任?

涛哥

产品经理

Breaking through Three Common Engineering Myths·英语阅读笔记

3.141516

新手村:最适合新手的 Redis 基础

多选参数

数据库 redis redis6.0.0

技术为帆,纵横四海- Lazada技术东南亚探索和成长之旅

技术为帆,纵横四海- Lazada技术东南亚探索和成长之旅

我们实施DevOps的挑战之三 —— 先流水线?还是工具化?-InfoQ