云服务器内容精选

  • CodeArts前端DevOps实践 本文主要以CodeArts产品自身为背景,简要介绍一些在前端性能优化方面的优秀实践方法和常见问题。 在开始本文的内容之前,先简单介绍一下华为云CodeArts。CodeArts是华为云一站式云端DevOps平台。简单来说,就是在云端提供了从需求到运维的端到端DevOps工具链。CodeArts的目的是为研发团队提高研发效率,降低研发成本。 本文的主题是前端的性能优化,而性能优化的解决过程与一个希腊神话故事十分类似。这个故事讲述一个名叫西西弗斯的国王,由于犯了错误,被惩罚在一座山坡上不停的推石头。这位国王不停推石头的过程,与我们持续的进行性能优化的过程很像,而石头就是我们要不停优化的问题,发现有问题又要重新来,或者一步一步来。几乎所有大型网站在做性能优化的时候,可能都是在重复的推那个大石头。 我们为什么要做性能优化?下面让我们来看几个数据: 第一,40%的用户如果在一个网站加载时长超过三秒之后就会离开这个网站。 第二,用户转换率和网站的响应时间进行关联的结果基本是,响应时间越高,性能越差,转换率越低。 之前在知乎上有一个很出名的讨论,有个人分享他把网站的响应时间从10秒提高到2秒,效率提高500%的心得和过程。当时很多人评论他讲得好,但还有更多人批判这个问题,原因就是为什么你最初能够容忍一个响应时间为10秒的产品上线?其实很多团队都存在这样的问题,每天聚焦在做优化的事情,反而忽略了第一次的10秒是怎么产生的。就好像西西弗斯的那个故事里的大石头,它为什么会出现?比如突然有一天我们被告知,用户说网站性能太差,无法承载响应的需求,这个时候团队内部才决定痛定思痛,好好做网站性能优化的事情。第一步往往是对网站进行分析,看能否找到其中的问题是什么。然后通过这些问题逐步去分析,并且做大量的技术验证,去定位并确定问题,这一步帮助我们知道这个石头是怎么来的。在这个阶段,让我们来看看有哪些好的实践。 首先,尽量利用一些第三方的平台工具,例如谷歌的Page Speed和YSlow、Lighthouse。这些工具提供了很多关于单一应用的检查项。用好第三方平台工具,能够快速对你的网站进行检验,去发现这里是否有问题,然后给我们某一个维度的检查报告。我们不能也全部依赖于工具的检验结果,也需要基于业务本身去一个一个验证,得出一个优化的结论,每一环验证好打上勾,最终的结果呈现出性能的提升。我们在提升的过程中往往发现,很多问题是规范方面的不足,这时就需要思考为什么在开发过程当中会犯这样的低级错误。 基于前面的过程,团队往往会组合出适合自己的工具链。但当我们一次次的开始推我们的这个大石头时,会发现石头特别大、特别累。于是我们希望前端工作人员能够安静独立的尽快解决这个事,不被打扰;我们会想团队要求能否少点需求,在这各阶段大家都停一下,一起把这个任务过了,让网站得到一些提升。 我们可能经过一个月的攻关,确保每个团队把自己的工作做好了,发上线了,客户得到了好的反馈,网站性能提升了,团队很高兴终于把这个石头推向山顶。但是过一两个月,又有人说页面速度变慢了,有些模块的响应速度完全不能忍受。问题的来源可能很多,我们的开发人员要专注于交付,项目进程中会出现人员的变动,很多之前在项目中积累的好实践会丢失掉。然而这些问题是无法避免的,可性能的提升也是刻不容缓的,难道团队要每隔一两个月就要做一次这样的攻关,又去推一遍超级大的石头吗? 在CodeArts的开发过程中也出现过这样的问题,而CodeArts团队针对这个问题的思考是不推这个石头了,为什么一定要积累到这么庞大的问题,而不是把石头敲碎,每次带一点呢。于是CodeArts开始基于这个角度思考如何进行性能优化,不要做任何专项的改进,而是把问题敲碎,放在每一个迭代当中。 回到开始,我们想一下之前要做的性能优化的事情,简单来说可以分为两个部分。第一个部分是固化的部分,包括CDN的建设、所有Web上的容器设置。CodeArts使用的是前端的Angular框架,关于Angular框架本身的演进与优化,再到基于业务实践自己抽取的或者实现的主权库以及公共的部分,我们把它看做是固化的部分。固化的意思是说在组织过一次集中的攻关之后,经验和效果很容易被传承下来。它的改动不涉及业务,所以它的变化频率本身比较低,而且一般这种公共的东西会有专门的架构师去看护。对于这部分内容,做了一部分优化之后就会有很好的效果。这其中还有网站劣化的部分,有可能每一个特性就是100到几百毫秒的差别,但是一个不注意,积累到一定程度之后,就会出现我们最开始所说的10秒页面。对于这部分问题CodeArts前端团队会怎么做?这就要回到DevOps的三步法,从左到右的流动,从右到左的反馈,以及持续学习的迭代。 这里的关键是第二步,从CodeArts面临的问题角度来看,就是我们怎么知道产品的每一个服务,每一个页面在什么时候开始发生了性能的劣化,就像那个石头一样是慢慢长大的。我们能否在每天,每个月,每个迭代随时发现它的变化,然后把石头敲碎,前提就是能否及时得到反馈。如果团队自身都不知道产品的性能是怎么样,靠外界,靠用户,靠其他人了解,到那个时候一看,石头就已经非常庞大了。所以核心的第一点是反馈,那么如何建立这个反馈? 第一,要有主动、实时的、前端定制化的监控。这里有几个非常关键的方面: 前端定制化。这种监控手段非常多,有各种各样的监控工具,大部分的实现原理是源于浏览器的关键节点。CodeArts本身基于开源的项目做了定制化的监控,一是将浏览器里面所有关于监控的指标细化了。 按照框架的要求,定义一些对产品要求更适合的指标,并且监控数据是实时的,并不是采样。监控的数据会提供给开发人员,每一个前端的开发人员会隔几天观察一下页面服务的现状表现如何,监控生成的结果一目了然,会帮助他们知道问题是由于网络还是由于基础框架、业务写法、效率、接口,通过前端主动化、定制化的监控,可以快速识别,且降低交付成本。 第二部分是被动的例行的性能验收。CodeArts团队会从测试验收的维度思考问题,有的团队确实疏忽了,或者初期没有建立起主动的意识,就需要靠被动的性能验收去给团队展示,让大家知道网站目前的情况,看到每一个页面发生的变化。 有了这两个主动的和被动的监控数据存在,让整个前端团队能够掌控到网站在性能上的实时变化,知道现在发生了什么问题,哪一块是我们的弱点,哪一块需要我们的开发人员去注意,哪一块需要公共架构成员去关注,这些都是非常重要的需要可视化的东西。 建立了相关的数据可视化以后,要怎么推行它?正如上文所说,要避免以前的那种专项的运动,因此要把每一次的性能优化放在每一个迭代,实际上影射的就是DevOps的第三步,每一个小迭代的快速优化和快速学习。这并不是一个技术活,这个问题的解决不依赖于某个技术手段或工具,因此这才是最麻烦的问题,它要求参与的每一个人有这方面的意识,提供了自动化工具和监控的可视化数据,但是不去实施,那么前面所做的所有努力就都白费了。针对这个问题最好的解决办法就是沟通,每一次的站会、周会,整个团队上下要有一个沟通的机制。在团队内部建立起良好的沟通氛围,所有数据可视化,且进行展示,团队的成员可以自发认领,且对于任务不惩罚,多主动激励,培养团队成员的主观能动性,在一次一次迭代过程中,让大家能够主动的去承担,去找到这些问题。最后很关键的一点是及时的激励或及时的反馈,每一个迭代都要看到客观数据的变化。因为前面已经建立了主动的和被动的监控数据,每次的迭代中你做的努力,或者你的松懈,会直接在下一周,或者下一个迭代会议里面产生相应的数据变化。这种可视化的反馈数据会产生及时的激励,让团队看到付出的所有努力都是值得的,那些主动思考问题、解决问题的团队一定会在可视化中脱颖而出,而不愿意改的问题一定会被放大出来。 最后回到原点,上文中一直吐槽西西弗斯,但换一个角度看他,还有一部分非常值得我们去学习的地方,就是一直向上不停歇,无论怎样,他永远在那个死循环里面推石头,也像CodeArts的精神,就像迭代一样,不断提升自己。一千个读者眼中有一千个哈姆雷特,希望本文中基于CodeArts分享的所有前端性能优化,以及实践上的尝试,能给各位开发者带来一定的启发,也希望文中提到的内容也能够为你日常的工作和实践提供帮助。 父主题: DevOps概览
  • 背景信息 华为端到端(HE2E)DevOps实施框架,是结合了多年研发经验并集合了业界先进的实践所形成的一套可操作可落地的敏捷开发方法论,如图1所示。 图1 HE2E DevOps实施框架 规划和设计 步骤①和②是业务(或者是客户)与技术之间进行产品规划,梳理产品整体脉络,以及进行产品规划实施设计,并控制需求粒度与拆分的过程。 软件开发的本质是为了解决问题,提供用户价值的,而不仅是为了提供功能。影响地图就是用来鉴别用户需求是什么,深层的根因是什么。 用户故事就是目标和需求的载体,以用户的场景来讲故事,便于在客户、业务与开发之间进行信息的传递。在这个过程中,独立的需求条目的堆积,很容易导致只能看到各个需求条目,不能从整个解决方案思考需求。用户故事以用户使用的场景为主线,将大的阶段点,及其细分的活动,以树状的结构进行梳理和展现,既可以看到独立的需求条目,又能够看到整体需求场景。 计划和跟踪、迭代开发 步骤③~⑩是Scrum框架过程,是主要的管理实践。 Scrum定义了一个相对完整的敏捷过程管理的框架。在CodeArts中,将Scrum的框架与团队日常的开发活动,很好的融合起来。主要的过程产物包括产品故事列表、迭代故事列表、潜在可交付的产品增量、以及过程中产生的问题列表;核心的团队活动包括Sprint计划会议、团队每日站会、Sprint演示会议、Sprint回顾会议等会议、以及团队的日常更新。 同时,将Kanban方法与Scrum框架进行了结合,团队借鉴Kanban方法中的精益思想,可视化价值流,发现并解决阻塞与瓶颈,加速价值流交付,并加快反馈回路,持续进行改进。 持续交付 从步骤⑪开始,进入到工程实践,也就是通常说的CI/CD过程。 持续交付以代码配置管理为基础,除了传统意义的代码资产安全与管控、多人并行开发、版本与基线管理外,也体现了团队的协作与沟通。 代码检查(即静态扫描)、自动化的构建、各阶段的自动化测试、以及相应的自动化部署过程,都被有机的串联在流水线上。 除了代码检查、构建、测试、部署等动态的阶段与活动,还有制品管理,以及各级的环境管理,包括开发环境、测试环境、准生产环境,以及生产环境。 持续交付流水线就是将整个持续交付中,都有哪些阶段,分别运行在什么环境,每个阶段执行什么活动,准入与准出的质量门禁,以及每个阶段的输入与输出的制品进行管理。
  • 方案架构 “凤凰商城”示例程序架构 “凤凰商城”示例程序的架构图如图2所示。 图2 凤凰商城技术架构图 示例程序由表1中的5个可以独立开发、测试和部署的微服务组件构成。 表1 凤凰商城微服务组件表 微服务组件 说明 Web用户端服务器(对应样例代码中的“Vote”功能) 业务逻辑:用户可以通过浏览器访问此服务的WebUI。当用户在特定商品上单击“Like”时,服务将用户所选择物品的记录保存在Redis缓存中。 技术栈:Python、Flask框架。 应用服务器:Gunicorn。 Web管理端服务器(对应样例代码中的“Result”功能) 业务逻辑:用户可以通过浏览器访问此服务的WebUI,会动态显示用户端UI上用户单击“Like”的统计数据,此数据来自PostgreSQL数据库。 技术栈:Node.js、express框架。 应用服务器:server.js。 后台订单批处理程序(对应样例代码中的“Worker”功能) 业务逻辑:此服务为后台进程,会监控Redis缓存中物品记录,并将新纪录取出并保存在PostgreSQL数据库中,以便管理端UI可以抽取数据进行统计显示。 技术栈:.net core或者Java(此服务提供两种技术栈实现了同样的功能,可根据需要修改配置选择其中一个作为运行时进程)。 订单缓存 业务逻辑:此服务作为用户端UI服务的数据持久化服务存在。 技术栈:Redis 订单数据库 业务逻辑:此服务作为管理端UI服务的数据源。 技术栈:PostgreSQL “DevOps全流程样例项目”构成 “DevOps全流程样例项目”是一个Scrum类型的模板项目,项目中预置了部分服务的使用模板。项目实践过程中涉及到的产品及服务如下表。 表2 实践涉及产品/服务列表 服务 说明 软件开发生产线 需求管理 预置3个已规划并已完成的迭代、项目的模块设置、以及若干统计报表。 代码托管 预置代码仓库“phoenix-sample”,存放项目示例代码。 代码检查 预置4个任务,任务详情介绍请参见步骤四:检查代码。 编译构建 预置5个任务,任务详情介绍请参见步骤五:构建应用。 制品仓库 用于存储通过构建任务生成的软件包。 部署 预置3个应用,应用详情介绍请参见步骤六:部署应用(CCE篇)。 测试计划 功能测试用例库,预置十余个测试用例。 流水线 预置5条流水线,流水线详情介绍请参见步骤八:配置流水线,实现持续交付。 说明: 购买专业版或企业版CodeArts套餐的用户,创建示例项目后可见5条流水线;购买体验版或基础版CodeArts套餐的用户,创建示例项目后只可见流水线“phoenix-workflow”,升级套餐至专业版或企业版后,需重新创建示例项目才可见5条流水线。 其它组件和服务 统一身份认证服务 用于管理账号。 容器镜像服务 用于存放构建任务生成的Docker镜像。 云容器引擎 用于软件包部署,与ECS部署属于两种不同的部署方式。 弹性云服务器 用于软件包部署,与CCE部署属于两种不同的部署方式。
  • 应用现状 ArgoCD是用于Kubernetes的声明性GitOps持续交付(CD)工具。ArgoCD以Git为核心,支持声明式定义各类对象,通过ArgoCD可以实现应用快速发布到Kubernetes中,并且能够根据版本标识快速跟踪和多集群部署功能,实现多个集群之间同一应用部署问题。 图1 Argo CD工作流程 本文介绍在ArgoCD中对接CCE执行持续部署的过程,并通过一个具体的示例演示该过程。
  • 监控和跟踪项目状态 每日站立会议跟踪任务进度。 迭代开始后,项目组通过每日站立会议沟通每个工作项的当前进展,并对工作项状态进行更新。 使用卡片模式能够简单直观的查看迭代中各工作项的当前状态。 进入“迭代”页面,单击图标,切换到卡片模式。页面中展示了处于每种状态下的工作项卡片,通过拖拽工作项卡片即可更新其状态。 迭代评审会议验收迭代成果。 在到达迭代的预计结束时间前,项目组召开迭代评审会议,展示当前迭代的工作成果。 “迭代”页面提供了迭代统计图表,团队可以方便的统计当前迭代的进度情况,包括需求完成情况、迭代燃尽图、工作量等。 进入“迭代”页面,单击“统计”,即可展开迭代进度视图。 仪表盘跟踪项目进展。 仪表盘提供了强大的项目进度跟进能力,包括需求进度统计、燃尽图、工作完成度、工时统计等,可随时查看项目的当前进展。 您可以使用内置的仪表盘报表卡片(详细使用方法请参考使用仪表盘),也可以根据需要自定义报表。
  • 操作流程 本文档将按照以下步骤介绍HE2E DevOps实践的操作流程。 图1 HE2E DevOps实践操作流程图 表1 HE2E DevOps实践操作流程说明 步骤 说明 实践准备 完成实践开始前的准备工作,包括创建项目、添加项目成员等操作。 管理项目规划 完成项目的整体规划,包括项目需求规划、迭代需求规划等。 管理项目配置 根据项目需求,对工作项变更的通知方式、工作项状态的流转方式等进行自定义设置。 开发代码 通过分支来进行代码的编写,包括创建分支、代码提交、合并分支等操作。 检查代码 对代码进行静态扫描,根据修复建议优化代码,提高代码质量。 构建应用 构建环境镜像、将代码编译打包成软件包。 部署应用 将构建好的环境镜像及软件包安装并运行在环境中,本文档提供两种环境的部署方法:CCE与ECS。 管理项目测试 为迭代创建测试计划、设计测试用例,并按照计划执行测试用例。 配置流水线 将代码检查、构建、部署等任务串联成流水线。当代码有更新时,可自动触发流水线,实现持续交付。 释放资源 实践完成,释放CodeArts、CCE等资源。 父主题: 华为端到端(HE2E)DevOps实践
  • 概述 本文以“DevOps全流程示例项目”为例,介绍如何部署应用至CCE与ECS。 开展实践前,需要完成编译构建。 样例项目中预置了以下3个部署应用。 其中,第一个用于CCE部署,第二、三个用于ECS部署。 表1 预置应用 预置应用 应用说明 phoenix-cd-cce 部署至CCE流程对应的应用。 phoenix-sample-standalone 部署至ECS流程对应的应用。 phoenix-sample-predeploy 向ECS中安装依赖工具操作对应的应用。 父主题: HE2E DevOps实践——部署应用
  • 监控和跟踪项目状态 每日站立会议跟踪任务进度。 迭代开始后,项目组通过每日站立会议沟通每个工作项的当前进展,并对工作项状态进行更新。 使用卡片模式能够简单直观的查看迭代中各工作项的当前状态。 进入“迭代”页面,单击图标,切换到卡片模式。页面中展示了处于每种状态下的工作项卡片,通过拖拽工作项卡片即可更新其状态。 迭代评审会议验收迭代成果。 在到达迭代的预计结束时间前,项目组召开迭代评审会议,展示当前迭代的工作成果。 “迭代”页面提供了迭代统计图表,团队可以方便的统计当前迭代的进度情况,包括需求完成情况、迭代燃尽图、工作量等。 进入“迭代”页面,单击“统计”,即可展开迭代进度视图。 仪表盘跟踪项目进展。 仪表盘提供了强大的项目进度跟进能力,包括需求进度统计、燃尽图、工作完成度、工时统计等,可随时查看项目的当前进展。 您可以使用内置的仪表盘报表卡片(详细使用方法请参考使用仪表盘),也可以根据需要自定义报表。
  • 验收标准 按照服务合同约定的范围,各服务子项验收标准提交交付件,客户官网单击验收确认、签字并盖章(含电子件)。 验收流程针对华为负责的文档类交付件; 交付件的验收以SOW中对交付件的描述和要求为准; 对交付件的验收应着重于对文档实质内容的验收,凡交付件实质内容符合本工作说明书约定的,应予通过验收和接受。少量格式、词汇、修饰等方面的不符不应被作为不验收的理由,但华为应就格式、词汇、修饰等方面的不符处按客户要求在合理的时间内进行修改; 在项目进程中,所有交付件都将经过客户和华为日常讨论和评审,以保证双方对文档内容的认识一致并缩短交付件的验收时间。客户应对华为提出的意见或要求及时提供其建议及批准。根据项目的实际情况,部分或所有交付件在验收签署之前将经过项目组评审、业务部门评审、并向领导组汇报。客户应负责在SOW约定的验收时点前推动(包括组织和安排顾问资源)并及时完成所有内部评审和汇报; 华为将根据上述评审和汇报的反馈意见,在5个工作日内完成对交付件的修改,并在指定的工时内提供全部服务由客户验收; 如果因非华为原因导致完成交付件审核和批准需要更多的时间,华为项目组将依据按工作说明书定义的变更控制流程签订的变更申请延展团队工作时间并获得相应付款; 在交付件验收签署后,如果要求对任何交付件的内容作增减,华为将对该增减所带来的工作复杂性及风险性进行评估(如对服务费用、时间计划和资源配备等的影响),包括由此带来项目费用及时间计划的更改,在得到双方的同意后予以执行; 对“企业软件研发能力诊断” 服务的交付件验收应着重于文档实质内容,凡交付件实质内容经客户确认,应予以验收通过。
  • 责任矩阵 阶段 服务条目 客户 华为 备注 阶段一:前期准备 收集企业信息 R S 企业软件研发能力诊断-增量包不涉及该服务条目 制定诊断计划 S R 阶段二:研发能力调研与诊断评估 现场调研与访谈 S R - 制定调研总结 S R - 编写诊断报告草案 S R - 专家评审 S R - 诊断报告定稿 S R - 阶段三:诊断验收 解读诊断报告 S R 企业软件研发能力诊断-增量包不涉及该服务条目 客户验收(企业/政府) R S
  • 服务内容 服务项 服务内容 企业软件研发能力诊断-园区版 主要针对区域政府客户提供的批量企业诊断套餐,从多维度对10个团队的研发能力进行评估,展现企业研发能力的优势与不足,并给出提升优化建议和解决方案,牵引企业持续提升研发能力。园区版可叠加购买 企业软件研发能力诊断-标准版 主要针对单个公司提供的诊断服务,从多维度对一个团队的研发能力进行评估,展现企业研发能力的优势与不足,并给出提升优化建议和解决方案,牵引企业持续提升研发能力 企业软件研发能力诊断-增量包 主要针对单个公司研发团队较多时提供的诊断服务增量包,从多维度对一个团队的研发能力进行评估,展现企业研发能力的优势与不足,并给出提升优化建议和解决方案,牵引企业持续提升研发能力。需要先购买标准版再购买增量包
  • 责任分工 共同责任 双方商定并确认具体服务目标及范围; 完成合同签订。 客户 提供详细准确的需求和场景; 诊断期间,客户需要指派一位项目负责人协助华为云专家,便于项目的顺利落地。此负责人应该承担双方的协调管理,并审核、验收华为云服务; 客户方需要协调具体的人员配合华为云专家达成企业软件研发能力诊断服务的实施,包括但不限于业务人员、管理人员、技术骨干等; 审核并确认华为提供的赋能计划和交付件。 华为云 接收用户的赋能申请,协调敏捷与DevOps专家赴与客户商定地点进行赋能; 赋能前,按照客户所选服务项,制定赋能计划和报价清单供客户审核确认; 赋能期间,依确认后的计划为指定学员进行赋能和技术指导; 赋能结束后,根据所选赋能服务项,出具交付件清单。
  • 服务交付件 将交付件整理后邮件提供给客户审阅,待客户负责人审阅通过并确认签字,赋能完成。交付件包括: 服务项 服务子项 交付件 备注 企业软件研发能力诊断 收集企业信息 《企业基本信息收集表.docx》 企业软件研发能力诊断-增量包不涉及该交付件 制定诊断计划 《诊断服务计划表.docx》 现场调研与访谈 - 制定调研总结 《企业研发能力诊断评估报告.docx》 编写诊断报告草案 《XX公司软件研发能力诊断报告.pptx》 专家评审 - 诊断报告定稿 《XX公司软件研发能力诊断报告.pptx》 《企业研发能力诊断评估报告.docx》 《区域诊断报告-华为XX合作调研报告模板.docx》(仅园区版涉及) 解读诊断报告 《XX公司软件研发能力诊断报告.pptx》 《区域诊断报告-华为XX合作调研报告模板.docx》(仅园区版涉及) 企业软件研发能力诊断-增量包不涉及该交付件 客户验收(企业/政府) -
  • 修订记录 发布日期 修订记录 2023-06-12 第十次正式发布。 部署服务修改环境配置,增加主机器群管理。 2023-02-25 第九次正式发布。 代码托管更新UI。 部署增加环境配置。 2023-02-16 第八次正式发布。 CloudIDE服务更名为CodeArts IDE Online。 代码检查、流水线上线新版UI。 2022-12-07 第七次正式发布。 软件开发平台更名为软件开发生产线。 项目管理服务更名为需求管理。 2022-08-11 第六次正式发布。 根据产品新UI布局更新截图。 2022-06-30 第五次正式发布。 在“部署应用(云容器引擎)”章节中,根据CCE服务新UI更新“购买并配置CCE环境”说明。 在“释放资源”章节中,根据CCE服务新UI更新“删除集群”说明。 2022-06-10 第四次正式发布。 在“实践准备工作”章节中,增加“开通软件开发生产线”说明。 2021-10-10 第三次正式发布。 在“构建应用”章节中增加“配置基础依赖镜像”说明。 在“部署应用(云容器引擎)”章节中增加“调整yaml文件配置”说明。 2021-03-09 第二次正式发布。 在附录中增加“构建加速”说明。 2020-10-21 第一次正式发布。 父主题: 华为端到端(HE2E)DevOps实践
  • 华为公司管理过程的变化 《科技想要什么》一书中,将科技比作生物。生物是在不断进化,伴随着科技生物的进化,科技生物的研发方法也在不断的进化。华为公司在过去三十年,从小型做硬件、做CT通信产品的公司,成为跨ICT公司,研发理念和思想上也在不断变化。经历了初步的CMM持续交付、持续集成到敏捷、DevOps,直到最新的进化状态CodeArts。下图是华为公司在过去三十年研发能力和研发方法以及研发的工具进化的过程。