# 一、DevOps-Platform项目
Devops(开发和运营的组合)是一组过程、方法和系统,用于促进开发(应用/软件工程)、技术运营和质量保证(QA)部门之间的沟通、合作和集成。 它是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间交流与合作的文化、运动或惯例。 通过自动化“软件交付”和“架构变更”的过程,可以更快、更频繁、更可靠地构建、测试和发布软件。
传统的软件组织将开发、IT运营和质量保证设置为独立的部门。在这种环境下,如何采用新的开发方法(如敏捷软件开发)是一个重要的课题: 按照以前的工作方法,开发和部署不需要IT支持或QA深入和跨部门的支持,而是需要极其密切的多部门合作。 然而,DevOps考虑的不仅仅是软件部署。它是一套过程和方法,旨在这些部门之间的沟通和合作。
DevOps的引入可以对产品交付、测试、功能开发和维护产生深远的影响(包括“热补丁”,以前很少见,现在很常见)。 在缺乏DevOps能力的组织中,开发和运营之间存在信息“鸿沟”——例如,运营商要求更好的可靠性和安全性, 开发人员希望基础设施响应更快,业务用户希望更快地向最终用户发布更多功能。这种信息差距是最常见的问题。
DevOps-Platform项目通过多角色紧密合作的开发者平台,通过包括敏捷项目管理、代码管理、CICD、自动化测试等工具,提升软件生产过程中团队协作。
# 1.1 DevOps-Platform项目背景
测试架构的演进
- 从有测试开始之初,是比较偏纯手工测试的方式,那就是大家说的“测试就是点点嘛”,这时候的测试“龟缩在测试阶段”,还经常被产品、研发压缩时间,可谓惨不忍睹。此时的测试阶段,效率低下,覆盖度不高,重复工作高,以黑盒测试为主,整体测试效率不高。
- 然后测试团队意识到,不能一直这样的,麻木的重复性点点,没有技术含量,自身成长也不高。此时,测试团队里有想法的小伙伴,开始把部分重复性工作,写成一些脚本工具,测试团队开始有部分工具支持,提升了部分测试效率。但从测试的深度和广度,并没有得到提升。还是停留在功能、UI层面测试。
- 接着为了提升深度和广度,开始有白盒测试,重新定义测试方法,深入代码级别的测试,此时从功能的黑盒测试,流转到了对代码的测试,然后测试和研发不在功能的bug上去沟通,而是测试指着代码给研发说,看这里有bug,应该怎么怎么改
- 这时候,测试发现我怎么比以前还累了,以前只要测试功能,不需要review代码。随着白盒测试的深入,codereview的时间占据了大部分时间,研发和产品说,你们能提升效率吗?然后测试开始思考,如何提升效率和质量,然后开始搭建自动化测试,持续集成,持续部署。部署流pipeline 随时检测业务代码。如此,降低了功能测试的覆盖,这时候测试同学,大部分时间在完善pipeline 和codereview。
- 此时团队来了一位架构师,开始思考,团队的质量体系如何建设,难道一直是流水线完善,怎么做到研发自测,测试不参与到具体的项目,提测研发测试比,从1:3 => 1:5 => 1:10 ,甚至部分业务无测试。这就需要研发在不断ci代码的同时,项目不断推进时,质量体系是一直默默的在“保护”项目的质量,要求对线下和线上,都能快速无感知的,发现问题,也就是devops开始了。
DevOps和应用程序生命周期
DevOps 影响应用程序生命周期的规划、开发、交付和运营阶段。每个阶段都依赖于其他阶段,并且这些阶段并非特定于角色。在真正的 DevOps 文化中,每个角色在某种程度上都涉及到每个阶段.
- 计划: 在计划阶段,DevOps 团队构思、定义和描述他们即将构建的应用程序和系统的特性和功能。他们在低粒度和高粒度级别上跟踪从单个产品任务到跨多个产品组合的任务进展。DevOps 团队以敏捷和直观地方式进行规划的一些方法包括创建积压工作 (backlog)、跟踪 bug、使用 scrum 管理敏捷软件开发、使用看板以及使用仪表板直观呈现进度。
- 开发: 开发阶段包括编码的各个方面(编写、测试、评审)、团队成员集成代码,以及将代码构建为可部署到各种环境中的生成工件。DevOps 团队寻求在不牺牲质量、稳定性和生产效率的情况下快速创新。为此,他们使用高效的工具、自动化单调和手动步骤,并通过自动化测试和持续集成以小增量迭代。
- 交付是以一致且可靠的方式将应用程序部署到生产环境中的过程。交付阶段还包括部署和配置构成这些环境的基础结构,该基础机构受到完全治理。在交付阶段,团队定义了具有明确手动批准阶段的发布管理流程。他们还设置了自动入口,用于推动应用程序经历各个阶段,直到提供给客户。这些流程的自动化使这些流程可伸缩、可重复并且可控制。这样,使用 DevOps 的团队就可以轻松、自信、放心地频繁交付。
- 运营: 运营阶段包括维护、监视和对生产环境中的应用程序进行故障排除。在采用 DevOps 做法时,团队致力于确保系统的可靠性、高可用性,并在加强安全性和治理的同时实现零停机的目标。DevOps 团队希望在问题影响客户体验之前发现问题,并在问题发生时迅速解决问题。保持这种警惕性需要丰富的遥测、可操作的警报以及全面了解程序和基础系统。
Devops的好处
- 标准化的流程: 如果需要做到devops,重要的前提是把项目和代码的流程标准化,各角色如何配合,各项目阶段如何做到准入。同时需要把人为的执行流程,使用工具管理起来。既保证了流程标准化,也同时对于项目的数据做到集中共享。推荐使用jira。
- 增加测试广度宽度: evops是一种框架,类似于一艘航母,需要装备“电磁炮”,“战斗机”,“核潜艇”等等,才能发挥最大作用。从项目开始,devops这艘航母就开始保障项目质量。从深度上讲,单测、模块自动化、集成自动化、系统自动化,多层覆盖;从广度上讲,功能测试、性能测试、兼容性测试、静(动)态代码扫描,多维度覆盖。这些测试组件,有的叫测试服务化,是devops最尖端的武器。在配合项目流程场景下,分别从代码开发、提测准入、功能回归、全链路压测、线上回归等等,对项目提供质量保障
- 提升整体质量: 没有devops时,测试服务(工具/平台)是游离在项目之外的,即使有工具平台,但缺少完善的使用场景,对于不同的业务,不同的端,不同的测试同学,所使用的工具平台是不一样的,同时对测试场景的制定,也需要线下制定,然后手动,非常费时成本较高。而devops是无需人力干预,从项目开始就在保障了,整个流程中,都是自动的,且在每个环节都有标准,保证质量的持续提升。此外,在不停地持续构建部署中,做到测试前置,在交付给QA的代码,是保证高质量的。
- 质量可度量: 一般评估项目的质量,是从项目效率、代码质量、服务稳定性、线上事故、用户反馈等几个维度来评估的。在devops中的各个武器,都需要对质量检测做数据输出,比如说自动化测试的代码覆盖度率、接口覆盖率、bug率等等;而项目管理工具,可以对项目的各阶段效率数据化;从线上监控,可以拿到事故的数据指标,什么级别,什么原因,影响面等等;用户反馈接口,获取用户的数据,并通过一定算法(后续文章可以解答),抽取有效信息并聚合。如此,线上、线下、用户侧多个场景拿到数据,评估整体项目的质量。
- 提高研发测试比: 基于高效,高质的持续部署方式,测试同学不用在执行重复低效的点点工作,而更多关注在如何提高devops的测试赋能(后续也会提到),这样devops第一批干掉了纯测试的同学(说真的,这些同学前景堪忧),这时候从常规的比例提高(1:3 => 1:5),而测试赋能,把测试技能输出给研发,这时候研发自测的效率和质量更高了,新功能测试的工作量降低了,测试的排期进一步压缩(1:5 => 1:7),而devops的武器库使得更多的项目,无需测试参与,极限情况下可以把比例压缩到1:10.这就是阿里之前提过的,干掉QA。正式通过devops方式,干掉了QA
# 1.2 DevOps-Platform项目设计
# 1.3 DevOps-Platform业务流程
# 1.4 DevOps-Platform项目功能
# 1.4.1 项目管理平台(Jira)
- 个人工作台
- 项目模板
- 需求管理
- 任务管理
- 缺陷管理
- 版本管理
- 分支关联
- 甘特图
- 迭代管理
- 看板视图
- 提测单
- 发布单
- 工作项管理
- 工作流
# 1.4.2 制品管理平台
- 通用制品管理
- 仓库管理
- 镜像管理
- Helm Chart管理
- 制品晋级
- 制品下载
# 1.4.3 自动化测试平台
- 单元测试
- 组件测试
- 集成测试
- 系统测试
- 用例管理
- 场景测试
- mock测试
- 线上巡检
- 测试报告
- 版本管理
- 用例录制
# 1.4.4 代码管理平台
- 应用管理
- 多分支合并
- MR审核
- 应用流水线
- 模板管理
- 单元测试
- 静态检查
- 编译
- 镜像构建
- 制品上传
- 流水线编排
- 项目流水线
- 配置分级复用
- 部署策略
- 容器部署
- 主机编译
# 1.4.5 自动化运维平台
- 系统环境监控日志采集
- 预警
- 异常处理
- 服务自动化部署
- 上线运维
- 链路追踪Skywalking
# 1.4.6 Devops数据度量分析
- 数据源对接
- 数据采集
- 数据分析
- 项目管理域度量
- 开发域度量
- 测试域度量
- 运维/运营嫉度量
- 质量报表
- 效率报表
# 1.5 DevOps-Platform项目亮点和难点
- 全自动化测试
- 系统功能服务化
- 系统微服务解耦
- 系统微服务容器化
- 服务的弹性伸缩
- 服务可观测性