Ghostcloud精灵云CTO乔融:基于Docker的DevOps实现
《Ghostcloud精灵云CTO乔融:基于Docker的DevOps实现》要点: 讲师介绍 乔融
主题简介:
一、传统开发模式的问题分析 众所周知,传统开发模式已经面临了诸多难题.首先,在代码集成方面,因为没有合适粒度的代码合并,大规模的合并会有很大的风险,且传统开发模式中没有自动化测试,以至于测试周期特别长,人力成本高昂.其次,传统开发中的单体应用,通常都很庞大,单体应用把所有模块都包含在一个应用中,升级单个模块也需要对整个应用进行升级,所以升级和创新都很不方便,常见的如银行系统就是如此. 同时,传统的开发模式中单独采用微服务的情况也会由于服务数量多而没有有效管理,在大批量的部署和测试的时候容易出现问题.除此之外,传统开发模式更面临着开发和测试的环境不一致,以及由于没有有效的升级方式导致业务停止的问题. 二、DevOps的完成流程详解 (如何一步步实现DevOps) 为了解决传统开发模式中的问题,目前一个比较流行和彻底的方案是:DevOps流程+微服务理论+使用容器和容器编排工具.在这里展示给大家的是一个理论上的基于容器的CI/CD流程,实际上,DevOps的前身就是CI/CD,实现了CI/CD后,再加上一些发布、部署等标准和管理就构成了DevOps. (基于容器的CI/CD流程) 三、基于Docker的DevOps实现步骤详解和案例分享 1、实现DevOps之自动化测试 那么,如何完整地实现DevOps呢?通常情况下,传统开发模式转向DevOps的第一步是解决自动化问题.要想持续地集成代码,没有自动化测试来保证快速地进行合并后的验证,风险是很高的,而且没有自动化测试,测试环境很有可能成为整个开发环节的瓶颈.只要是经常使用的测试用例,需要尽量自动化每一个操作. 自动化工具很多,对自动化工具和测试框架的选择需要根据具体应用来决定,这里只列举其中常用的一小部分——Jenkins、Python、Robot Framework、Shell Script、Selenium、Ansible和Docker Container Orchestration——这些都是我们面对客户需求的时候经常用到的.然而,不是每次集成都需要跑完所有的测试用例,因而对测试用例进行管理,可提高持续集成的效率. (自动化测试) 如何来判断自动化测试用例和框架是否有效?常见的判断依据有三个,首先是自动化测试的覆盖率.如果通过率再高,覆盖率低,那么自动化测试就不是一个有效的,目前企业级比较认可的覆盖率是75%左右,再提高也比较困难.其次是看漏测率,有时候自动化用例本身也可能有Bug,前期阶段通过比较手动测试、自动化测试的结果来判断自动化测试是否有效.最后,当产品发布后根据从客户来源的bug数目来判断自动化测试用例是否有效.另外,要稳定一套自动化用例,一般需要2个版本周期或者更长. 2、实现DevOps之持续集成和持续交付 持续集成一个主要的功能是让每个工程师的代码提交都不会影响到Mainline,以保证Mainline的可发布状态.实施持续集成时,需要注意的地方:指定规则,提交代码时要一并提交新功能的测试用例. 集成的粒度和频度也很关键.一般一个小模块,不超过1周的时间. (持续集成) 持续集成通过后,根据应用程序的特点,在经过系统集成测试、性能测试、稳定的自动化测试通过率以及管理层的批准后,才是可持续交付和部署的应用程序. 持续交付有两种方式,一种就是基于DevOps的自动持续发布,一种是多个功能一并发布.在持续交付的过程中需要注意三个问题:
3、实现DevOps之微服务化 有了自动化测试、持续集成和持续交付三块,已经基本实现了DevOps的粗略流程,而为了提高DevOps的效率,往往需要结合微服务.一个微服务理论上只做一件事,并能用任何语言编写.微服务是松耦合的,意味着一个应用的微服务可以被部署到不同机器上并通过RestAPI/RPC来通信,当定义好微服务的API之后,每个team便能独立开发.因此,微服务更容易被测试和实现CI/CD. (微服务的最佳实践) (编辑:ASP站长网) |