TA的每日心情 | 开心 2019-9-23 15:20 |
---|
签到天数: 64 天 连续签到: 1 天 [LV.6]测试旅长
|
DevOps是什么呢?百度百科给出的定义:DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合,其目的是达到业务的快速交付。
看到这里,大家对DevOps有了一个整体的概念。但是不是还是觉得很抽象?看到这儿笔者也这么认为,那么到底DevOps是什么以及如何落地呢?
其实,一方面,比较认同DevOps是工具的集合,是通过工具链打通业务、开发、测试、运维的部门墙,最终实现端到端的部署流水线。笔者认为不管DevOps的文化和理念多么高大尚,最终落地还是需要靠工具。另一方面,笔者认为监控和快速反馈也是DevOps成功非常重要的部分,在通过工具集加速软件生产过程中,对流水线的监控是非常必要的,这样在任何环节出现问题,可以快速反馈到主责部门,主责部门才可以快速去解决问题,并打通流水线的阻塞,形成闭环,达到业务快速交付的目的。
下面给出实现DevOps落地思路的开源工具集:
1、 Maven或gradle:管理依赖;
2、 GitLab:实现代码管理、代码协作、需求管理和看板管理;
3、 Junit:实现单元测试,构建内建质量;
4、 SonarQube:可视化代码质量,度量技术债务;
5、 Docker:管理镜像,保证测试、RC(预投产环境)等环境的一致性;
6、 Selenium/Appium/TestNg:实现接口自动化和功能自动化测试,提高测试质量和效率,实现质量快速反馈;
7、 HARBOR:管理镜像制品库,镜像管理、存储、分发全覆盖;
8、 Kubernetes:实现运行环境容器化,搞定容器编排;
9、 ELK :实时可视化生产环境数据,搞定分析度量。
10、 Jenkins定义可视化流水线进行过程监控,持续交付引擎,支撑持续交付过程;
结合开源工具集DevOps流水线执行过程简要描述如下:
1、 开发:基于新特性,需求从GitLab的看板中创建需求任务,开发将任务拖到看板的doing一栏并从master上拉取分支,建立自己的特性分支;完成单元测试代码和功能代码后进行特性代码构建;
2、 开发:构建完成触发Junit进行单元测试;
3、 开发:单元测试通过后,触发SonarQube进行代码静态扫描;
4、 开发:静态扫描通过后,将特性分支合并到Master分支,Master分支构建;
5、 开发:构建完成触发Master单元测试;
6、 开发:测试通过后,触发构建docker镜像;
7、 开发:部署到测试环境;
8、 测试:自动触发TestNg接口自动化测试和Selenium(Appium)功能自动化测试;
9、 测试:测试通过后,进行必要的手工测试;
10、 测试:测试通过后自动部署到RC环境;
11、 业务:自动化测试脚本在RC环境进行业务验证;
12、 运维:验证通过后自动部署到生产环境;
13、 运维:生产环境数据收集和监控;
下面以测试环节为例,介绍下测试部门和开发部门是如何打通部门墙的:
1、 开发阶段:自动化测试人员同开发人员并行编写自动化代码,将写完的代码放到GitLab库中等待测试环境分支构建;
2、 测试环境构建:通过Jenkins监控测试分支,测试分支构建完后自动触发接口自动化和功能自动化测试执行;
3、 自动化测试执行:自动化测试执行完毕之后自动发送邮件通知相关干系人并自动触发后续环节。
笔者认为,DevOps的最终实施需要群策群力,克服软件生产流水线各个环节遇到挑战。依旧以测试环节为例,DevOps实施可预见的问题或挑战包括:
1、 开发和测试自动化不能完全并行开展;
2、 人机交互的功能无法自动化实现,仍然依赖于手工;
3、 DevOps开展之后,持续化部署带来的自动化测试投入不足;
4、 DevOps开展之后,快速交付会带来的质量覆盖率不足等;
本文介绍了通过开源工具链实现DevOps落地的一种思路并结合测试环节进行举例,以此抛砖引玉,希望可以启发更多的思路。最后,需要说明的一点,虽然DevOps通过工具可以有效的落地,但是要实施好DevOps却离不开标准或规范。以自动化测试为例,如果要完全通过自动化测试进行DevOps的质量保证工作,减少手工干预,根据自动化测试金字塔原理需要采用分层的测试策略,即70%的单元测试,20%的接口自动化测试和10%的UI自动化测试。而这些百分比都可以认为是标准,只有满足了这些标准,DevOps质量保证环节才能更好的实现快速交付。
|
|