背景介绍
本期分享内容为 《平台化 DevOps—云计算与云原生模式下 DevOps 的建设实际》。目前，DevOps 越来越成为大家以后建设的热点，随同着基础设施的转型和利用框架的转型，更多的业务偏差云端和 C 端的场景，促成了 DevOps 的倒退。在本次沙龙上，腾讯云 CODING DevOps 资深架构师余朋飞为大家介绍了在云计算和云原生两种模式下，如何推动 DevOps 的建设和实际。
企业 IT 架构演变历程
在 2007 年之前，企业还未产生 DevOps 的概念，大多还是基于物理机的模式。2012-2014 年是第一波上云的热潮，企业纷纷将传统的物理硬件转换到虚拟机的构造上。之后，容器的倒退推动了利用的转型，微服务越来越被大家所提及，对应 DevOps 这个概念也越来越被大家所推崇。所以第二波上云是业务从底层迁徙到云上。第三波是云原生，整个 IT 基础设施，无论是从硬件端、中间件以及所依赖的数据库等资源全副可能在云上提供服务。基于这个模式，更应该被关注的是整个软件开发自身业务需要的梳理，到整个业务的经营，这个阶段从开发态，从经营态和服务调度的模式都有新的改善。
DevOps 始终致力于怎么更好地保护利用的生命周期。在 DevOps 1.0 时代，这个时代是将根底资源做标准化，更多的是针对利用架构采取单体或服务总线的架构，对应的模式还是以虚拟化为主。然而在整个业务倒退过程中，更应该面向的是 DevOps 2.0 服务治理，整个利用架构和基础设施的架构随之也会变动。接下来就具体看一看在这两种不同的管理模式下，整个 DevOps 的建设到底是什么样的形式去推动和落地它的。
云计算模式下的 DevOps
业务上云给大家带来了什么？咱们须要解决哪些问题？以下总结了几方面目前业界比较关心的点。首先因为基础设施的爆炸式增长，导致环境配置管理和保护愈发艰难，继续部署层面须要公布的节点越来越简单；在业务推向虚拟化基础设施的时代下，业务架构变得更加简单，对应部署成功率，相应的零碎稳定性也会降落；另外因为底层云资源带来的便当，在流量冲击的状况下须要做好资源和利用的弹性；最初，随着业务对 IT 的诉求越来越频繁，须要更疾速反馈整个业务的诉求。
因而，DevOps 的建设火烧眉毛，从需要到最终上线经营的全生命周期里须要进行全方位改良——比方须要更好更规范的需要管理工具，须要通过自动化伎俩疾速治理对应的环境，可能通过自动化测试把品质建设起来，最初可能更好地解决在经营阶段的事变。在这个阶段，大家更聚焦的外围是自动化，怎么通过 DevOps 的伎俩来强化自动化流程。在自动化成果根底上随同的是标准化和版本化，在自动化的同时也要做好相应的品质内建以及 DevOps 过程度量，因为只有将过程度量好之后能力评估 DevOps 建设的成果，品质内建也是保障 DevOps 建设过程中软件的品质可能失去很好的管制。
从这几个指标来看，外围指标包含生产效率、软件研发效率，生产管制中的产品质量，对应的老本节俭。在软件研发过程中，通过牢靠、可反复的流水线能够帮忙咱们更疾速、更高效地生产 IT 软件或对应的服务。
CODING DevOps 流水线实际
下图为以后 CODING 面向客户所推的 DevOps 流水线实际。
基于 CODING 平台，从代码拉取开始，基于内置的代码动态扫描模块来保障代码动态查看，蕴含代码标准、缺点、反复率等不同的维度，另外，云端的构建环境可能保障各种不同的构建编译，联合基础设施的治理可能将自动化部署到对应的测试环境，帮忙在整个流水线过程中做到测试品质治理，让品质在整个流水线过程中有比拟好的保障。最初，繁多的制品起源可能保障独立存储制品。到了生产阶段，咱们更多关注基于业务经营的过程怎么做灰度和 A/B Test 的部署模式。
研发标准
在建设流水线时，须要遵循一系列的研发标准。
流水线建设过程中须要将这些标准囊括起来，流水线并不只是打包工具，不是通过流水线将代码构建成制品就完结了，而是可能在流水线过程中标准化整个研发过程。
理解了这些标准，理论应该怎么去落地？在建设 DevOps 的过程中经常遇到许多令人苦楚的问题。比方，针对金融行业大量已有零碎，研发管理模式不尽相同，标准过多该如何治理？新老零碎和业务如何兼容？随着工夫增长、流程紧急、业务压力减少，如何保障团队的热诚和标准的长久运行？标准须要对应的人员去撑持，工作场景往往相当简单，如何做好标准的标准化工作？CODING 基于之前的教训，针对这些痛点研发了一款研发标准产品 TCMS，定义不同的研发团队所对应的研发治理流程，可能束缚对应的需要、代码、流水线治理，做标准化的束缚来晋升整个团队的合作效率。
研发治理包含几个局部。首先定义研发工作流，须要定义代码能拉出哪几个分支，容许哪些对应的合并策略，并且每次合并必须要有对应的标准和理由；第二，不同的合并规定意味着不同流水线的执行，在合开发分支的时候，开发人员做了一次本地提交可能只须要运行开发流水线，只须要对代码的品质和单元测试做一些束缚即可，一旦波及到 release 分支或 MR 的合并，这时候意味着性能合流了，基于合流规定来关联流水线，在流水线过程中去束缚这个合流所对应的业务规定；第三，自动化工具辅助分支治理，如果定义了一个分支只能拉进去一周，一周之内必须合并进去的话也会做一些束缚；第四，将对应的分支和需要治理关联起来，分支在合流的时候可能很清晰地从需要治理追溯到代码开发，从代码开发再追溯到整个业务合并，全生命周期治理是可管制和便于查阅的。
下图为 CODING 的标准化流水线：
云原生带来的扭转
从 CODING 以后服务的客户，一块是挪动端的业务，以后挪动端 APP 曾经越来越多的企业器重云原生，针对挪动端也是可能基于云让开发速度失去更好的保障另一块是从金融行业，有些营销类业务更多适应云原生的场景。无论是营销类也好，还是 APP 类也好，外围挑战是 C 端用户过多的状况下业务会受到较大制约，比方收集更多的用户数据，更疾速地对用户诉求失去反馈。单单通过流水线建设是无奈达到这个成果的，流水线只能帮忙咱们更快地实现代码到构建到部署这一段的效率，然而之后怎么基于部署的利用来晋升业务价值，就波及到价值交付的过程。在以后的 DevOps 2.0 外面，经营过程和业务剖析过程被纳入到 DevOps 体系外面去实现相应的价值交付。
那么怎么做价值交付？CODING 第一步会做自动化，第二步会做麻利。至于为什么把麻利放在 DevOps、自动化之后去建设，CODING 发现，在国内、尤其是大型机构和金融企业外面，麻利没有推得像大家设想的那么好。自动化设施没有做到肯定水平的时候是不足以撑持过于短平快的迭代的。所以 CODING 首先通过牢靠可反复的流水线建设自动化的利用交付体系，帮忙代码可能更快上线；而后基于麻利的思维和实际对业务需要做拆分和治理，通过迭代做增量式开发。另外随着对迭代的要求越来越高，CODING 每天都会进行公布，麻利曾经不足以撑持业务需要的增长，因而 CODING 团队更加贴合互联网模式去做微服务革新，利用架构变动之后，利用更小更细，就能更快地实现迭代。最初，业务上线之后经营过程也能够纳入到对应的 DevOps 体系外面来。
下图为 CODING 在价值交付体系下的组织构造转型：
在价值交付体系外面，CODING 从组织、流程、能效和工具四个层面做梳理。基于对应的 DevOps 指标可能评估团队对应的 DevOps 能效如何，怎么基于这些指标进行晋升。
通过 DevOps 的建设，企业可能通过容器化构建和开发环境治理，升高资源利用率和节省成本。CODING 提供了构建的资源池，大家在做开发的时候不须要本人治理服务器；另外，通过 CODING 流水线建设做到对应的继续交付的成果；基于 CODING 的施行也能更好地建设合乎 DevOps 文化的度量体系；标准化制品治理可能治理制品模板、流转和进阶的过程；最初，基于研发标准的束缚可能让整个团队在落地 DevOps 的时候更加无感，大家自觉遵守束缚以进步开发标准化。这是 CODING 的愿景——让开发更简略。
Q & A
Q：落地 DevOps 必然会面临团队成熟度的问题，包含团队技术水平，麻利意识和能力，如何保障标准化的产品在每个团队做更灵便的适配？
A：从 CODING 的角度来看，标准有两个不同的角色，标准的制定者和应用标准的人。只有对业务有粗浅理解的人可能制订标准。一些经验不足的同学，只须要基于以后制订的标准应用这个产品就能够了。
Q：在小公司外面，如何在老本管制和 DevOps 的落地之间获得均衡？
A：DevOps 从某种程度上是降低成本的。CODING 可能提供虚拟化的空间资源池让开发资源失去更好的利用。推动 DevOps 麻利也是为了让大家的工作效率协同模式失去更好的保障。随着对于利用品质的管控，将品质治理做到流水线过程中，可能让问题发现的环节更加前置，花更小的老本去修复问题。
点击观看课程录播并下载 PPT