对艾瑞咨询发布的中国DevOps应用发展研究报告的一些思考

　　今天这篇文章作为我阅读艾瑞咨询发布的《2020年中国DevOps应用发展研究报告》的一个思考整理，这篇报告在网上可以自行下载阅读，因此报告里面很多内容我不再重复叙述，重点是阅读过程中对DevOps市场和发展趋势的一些思考整理。DevOps究竟是什么？
　　DevOps一词是＂Development开发＂和＂Operations运维＂ 两个词的组合，中文一般译为＂开发运维一体化＂。虽 然在IT领域DevOps早已得到了业界的普遍认可并被投入各个领域的广泛应用，但目前行业内对DevOps还没有统一明确 定义。
　　参考全球头部IT公司对DevOps的理解，文中给出一个DevOps解释如下：
　　我们发现DevOps不是单一的技术或者工具，甚至不只是一个流程，它可以被理解为一系列可以高速、高质量进行软件开发的工具链，这种模式不仅提高了软件开发的效率和最终产品的表现，更是 现代IT企业协作及共享文化的体现和应用。
　　简单来说DevOps不是单一的技术，工具或流程，而是这些的一个结合体，体现的是在软件持续开发和交付过程中的管理类+技术类最佳实践。为了实现这个最佳实践你需要。处理好研发，QA，运维三个角色之间的关系和协同实施一套敏捷的研发流程采用一系列的工具和技术来实现自动化和智能化
　　对于DevOps的前身，可以理解为CI/CD持续集成和持续部署思想，包括在整个过程中的每日构建，自动化单元测试和冒烟测试等。随着整个微服务，云原生整体技术体系的不断成熟，整个DevOps实际是朝研发和运维两端进行延伸。
　　在朝研发端延伸的过程中进一步整合了Scrum敏捷研发方法论和过程管理，在朝运维端延伸的时候进一步整合了持续交付和智能化运维。同时对于CI/CD本身又对测试管理，自动化测试进行了加强，真正将研发，测试，运维三者衔接起来。
　　所以要实施DevOps，一个最小集合应该如下：敏捷研发+CI/CD+自动化测试+持续交付。同时其本身又会变成了一个闭环的持续优化和迭代过程。企业为何要实施DevOps
　　企业为何要实施DevOps，如果从字面理解难度仅仅是为了研发和运维之间更好的协同？如果这个问题没有思考清楚，那么很难将DevOps实施成功。
　　对于DevOps实践，仍然要回到两个根本性问题上。研发集成和交付效率IT管控治理水平
　　对于DevOps的实施始终都是围绕这两个点展开。
　　其一是研发集成和交付效率，整个研发过程，集成和部署过程，由于实施了DevOps后，整个集成和交付更加自动化，能够实现更加敏捷的短周期交付。这个不仅仅是解放了人力资源降低了成本，更加重要的是提升了整个软件开发和业务需求的敏捷响应速度。
　　其二是甲方本身的IT治理管控能力提升需求，在原来我谈到甲方引入了很多外包开发商，可以通过DevOps实施在类似开发，测试，安全检查，交付等各个阶段增加检查点，实现对整个研发全过程的可视化管控。同时及时没有引入外包开发商，对于大型企业自有IT团队往往上百人或者几百人，这种情况也需要考虑引入DevOps来实现研发过程可视化管控。
　　大家要注意一点，在云原生发展下，对于资源层的运维都会转向类似阿里云等公有云服务厂商来统一提供，企业更多的是做服务层和应用层运维监控。
　　在这种情况下可以看到后续企业研发团队实际上没有专门的运维人员，而是由技术人员来兼顾应用层运维工作。这本身就是一个大的发展趋势，传统运维或工程人员要有这个风险意识。否则传统运维人员自己就要转型到应用层，属性应用层和业务运维内容。
　　研发运维一体化，对于企业端来讲，不是还保留研发和运维两个岗位角色，而是完全专职化的偏资源运维岗位没有了，而是变成了研发人员的一个兼顾角色。
　　这个观点我也是第一次提出，请大家仔细思考。
　　IT管控核心是研发资产可视化
　　记得是有一个晚上，朋友突然找我让我出去聊下有急事，过去后才知道是由于内部管理或利益分配的诸多原因，在这里不方便细问，这个开发负责人逐步要离职走准备去单独干，而且可能还准备把几个核心开发都带走。由于我朋友本身也不是技术和IT出身，遇到这种事情本身还是一抹黑找不到对策，找到我的原因无碍乎是问我这边的技术人员或团队能不能先把他那边的系统和开发工作先承接过去下。
　　前期没有完整的研发流程，需求文档也不完善，而且在离职的时候提交的文档，代码是否完备这些即使是有经验的技术人员去验证本身也存在相当的难度，到了最后离职谈判阶段实际上我朋友本身已经处于相当被动的地位。
　　在这个时候来谈工作交接或找人接替本身也为时已晚。而实际上具体分析个人理解实际上这个问题很多非技术背景的领导都会遇到，造成的原因主要是。1. 核心研发资产，包括需求设计文档，源代码往往掌控在关键的一个人手里面，或者干脆无文档
　　2. 研发过程不透明，研发资产没有显性化，他人很难短期接手
　　而要解决这个问题，个人理解至少需要从几个方面来考虑，第一就是我们常说的研发团队划分，岗位角色设置上面要考虑分离，关键岗位角色要考虑有备份和AB角，能够相互替代。第二就是我们说的研发过程流程改进，研发资产的可视化。
　　而对于第二点，实施DevOps平台本身就是一个很好的支撑，即研发资产可视，过程可视，你每天新产生的代码都要检入，并进行相关的代码检查和自动化测试，整个持续集成和自动化构建确保了进入到我们配置管理库的代码是编译通过的。其次，我们自动构建完成的部署包本身就是推送给测试人员进行测试的部署包，中间不需要开发人员去插手或增加小动作，那么测试人员测试通过的版本，一定就是当前代码已经实现的版本。
　　即在整个DevOps持续集成过程中，实现了研发资产的持续落地可视化，这个可视化不仅仅是整个研发版本的可视，更是中间各个阶段的可视化，即使你团队所有人员都离职，我们也应该能够确保当前研发资产库里面的代码能够自动化构建完成并形成当前的应用版本。代码当前是全的没有遗漏，而且代码完全和当前功能对应。
　　还有就是，在实施SOA项目的过程中，我们也经常和甲方沟通，当时有一个甲方就提到一个关键点，当要给完整的业务系统招标选择了要给供应商来定制开发后，在项目验收完成后虽然提交了相关的文档，相关的源代码，但是发现后续的运维甲方根本无法承接。包括乙方提供的源代码本身都无法编译通过，即使能够编译通过构建出来的版本功能也和当前生产环境功能有明显差异。甲方如果本身不是专业的IT类公司实际上很难在验收的时候发现这些问题，也就是说最终验收你得到的文档，代码等内容实际上完全无法支撑甲方运维。
　　而这个问题和前面一个问题很类似，就甲方来说如何加强对开发商的管控，如何确保开发商定制的系统版本和当前的研发文档，源代码资产等是时刻同步的。如何确保最终验收的研发交付文档，代码就是和当前生产环境运行的系统版本是一致的？
　　如果所有的事情都到了验收的时候才去处理，那么往往为时已晚，说得直白一点对应乙方提供给甲方的业务系统对甲方来说就是一个黑盒子，里面的东西甲方完全搞不懂，只有乙方能够进行后续运维和定制维护。也就是甲方不得不承认间接被乙方绑架的事实。
　　我们都知道最终的研发资产要能够移交，要能够可交维，但是里面的关键点究竟在哪里？
　　简单来说就是研发资产的可交付必须是一个在一开始就持续增量不间断进行的过程，一个是按阶段进行持续的交付，一个就是按业务系统的功能点进行持续集成交付。在整个过程中会分很多小的阶段点，在这些阶段点都需要植入相应的自动化检查和测试手段，确保最终入库的资产质量是满足的。整个持续集成过程在一开始配置完成后，研发人员就不应该过多地介入，而应该是流水线自动进行，确保中间没有人为不确定性因素的加入。
　　微服务架构和容器云推动DevOps大发展
　　注意，在企业没有实施容器云，微服务架构改造的时候，实际前面谈到的持续集成，部署等工作量并不大，因此企业也很少单纯为了提升交付效率而实施DevOps。
　　但是在实施微服务后，你会发现原来的一个大单体应用拆分为了20个微服务甚至更多，每个微服务都涉及到编译，构建，打包部署等动作。整个集成和部署的工作量就大大增加了。
　　因此你不得不考虑进一步将这些工作自动化掉。
　　比如我们采用Jekins来实现整个CI/CD过程，同时将Jeins和敏捷研发，自动化测试工具或脚本，容器云交付平台进行集成，实现整个过程的自动化。
　　在这里提出一个重要观点，即：
　　在信息技术发展过程中，当采用和实践一个新技术的时候，往往会引入新的问题，这个时候我们不会是退回原点，而是进一步应用新的方法工具来解决新问题。DevOps实践流程
　　从DevOps的流程实践上看，总体来说其流程可以分为需求对接和应用设计、敏捷开发和持续测试以及最终测试和上线运维等三个阶段，其核心是由开发人员和测试人员主导的敏捷开发和持续测试阶段。借助Scrum或Kanban等工作流方法的和一系列持续构建、持续集成、持续测试以及持续发布工具，IT团队能够高效率地开发通过微服务架构解耦的程序模块， 并及时、持续地与用户方面进行对接，对各个模块的研发质量和成果进行实时把控。
　　在通过最终的集成和测试之后软件得以部署上线，此后开发人员能够借助应用容器化封装带来的统一环境之便，与运维人员一起对软件的运行质量进行监控、 为用户提供支持服务，并继续根据市场需求进行版本更迭的进一步开发工作。
　　在谈DevOps成熟度模型的时候我谈到过，简单来说DevOps最佳实践包括了三个方面的关键内容，即：敏捷研发和过程管理（引入微服务开发实践）CI/CD(扩展持续交付+自动化测试）运维管理（扩展到持续闭环技术运营）
　　只有围绕上面几个点，那么整个DevOps实践相对来说就是完整的。
　　敏捷研发和微服务
　　大家一定要注意，在实施微服务后对整个DevOps过程的一些影响。
　　一个传统的单体应用你要走CI/CD相当来说很容易，但是传统单体应用以及拆分为上10个甚至更多的微服务，这个时候你需要考虑。
　　你最终交付的是整个产品或应用，但是一个项目版本或变更过来，实际只变化了里面的3个微服务，那么如何仅仅交付和变更这三个微服务。
　　其次你还需要考虑，在进行持续集成的时候，不是单个微服务的编译构建，打包部署，这里面还涉及到独立的多个微服务间的横向集成，这个集成能否在DevOps过程中一并考虑到。(注：实际这块涉及到传统CMMI里面讲的PI产品集成的内容）。
　　为了实现这些，你可以看到产品，项目，项目版本，团队，团队成员，应用，微服务，API接口这些对象之间的关系变复杂了，需要梳理清楚这些对象之间的关系才能够构建完整的底层业务对象模型，同时需要实施类似多流水线设计等才能够满足以上业务场景。
　　这些内容在传统的DevOps技术工具链中不会谈到，而你在实施微服务和敏捷研发的最佳实践中一定会出现。也正是因为这个原因，我一直在强调。DevOps的核心是敏捷研发+持续集成交付的最佳实践，而非简单工具或技术的集成。
　　敏捷体现的一个关键点-环境迁移
　　实际我多次强调，DevOps在实现持续集成和持续交付过程中，有一个关键点就是环境迁移能力，即基于镜像文件和二进制包文件的快速迁移能力。
　　比如对于SIT测试通过的软件产品，我们可以做到一键将其迁移和部署到UAT测试环境供用户进行UAT验收测试，同时对于UAT测试通过的版本我们也可以一键迁移和交付到公有云服务平台。
　　这个不仅仅是敏捷交付效率，更加重要的是迁移过程不再重新编译构建，确保测试完成的内容就是最终交付的内容。
　　持续集成，持续部署，持续交付
　　这三个概念实际很多时候并没有区分太清楚，个人进一步说明为持续集成过程一定涉及到重新的编译构建，打包部署。而持续部署过程可以不涉及重新编译构建，仅仅是打包部署。持续部署可以是SIT环境到UAT，也可以是UAT到生产。而对于持续交付一般特制整个应用向生产环境和最终用户交付的过程，也就是用户最终使用到新的版本才完成交付动作。
　　DevOps落地实施路径
　　在报告中给出了一个DevOps从资源整合到自动化逐步实施DevOps的落地实施路径。
　　一般而言，企业实现DevOps的落地需要经历五个阶段，首先要实现企业内部的资源整合，提高资产和任务的可见性；其次是构建统一、流畅的线上和线下工作环境及流程，接着要搭建能够有效合作的团队体系，加强资源的共享；然后借助一 系列信息化的DevOps工具构建企业的自动化开发运维流水线，并生成相应的管理指标体系；自动化水平发展到一定水平 并且累计了充足的服务经验后，运维侧即能以标准化的形式为用户提供更高效便捷的服务。
　　对于DevOps实施，我更偏向于是整个云原生和微服务架构转型过程中的一个配套。即DevOps是配合容器云，微服务架构实施过程中的一个关键支撑过程。
　　如果按照这个思路，那么DevOps实施可以分为三个大阶段迭代一：CI/CD+微服务敏捷研发+容器云迭代二：实施自动化测试等核心过程管控迭代三：实施自动化运维和AIOps能力
　　对于迭代一种涉及到的CI/CD，微服务和敏捷研发过程管理，容器云，从远行科技实施DevOps经验来看一起实施是更好的做法。而对于自动化测试，自动化运维等则可以放到后续阶段进行实施。DevOps应用行业和场景
　　在报告里面分传统行业和科技行业对DevOps应用行业和场景进行了说明。
　　在我国数字化转型的大趋势下，找到适合企业的高效数字化转型道路将意味着在市场竞争中取得先机； 对于政府部门而言，将能够更好地构建数字政府和数字政府服务体系，提高地区乃至全国的信息化基础设施水平。在传统行业中，金融和能源等行业由于资金充足、技术实力相对领先，且对于各类软件和在线应用的需求较高，在传统行业中走在数字化升级的前列，也是率先引入DevOps方法和工具的行业。而新零售、智能制造等近年来逐步兴起的互联网+行业 也正在积极拓展互联网能力构建渠道以及市场优势。
　　注：传统行业类似大金融机构，电信行业，电网等能源行业往往实施DevOps都比较早，很多企业基本都是以自建DevOps平台并实施整体云原生方式进行。对于DevOps实施一个是用于内部IT团队，另外一个关键因素还是应用到IT外包团队研发产品和过程管控。
　　政府行业实际DevOps实施过程相对滞后，在智慧城市和智慧政务等推进过程中，往往是配合云原生整体进行DevOps过程实践。
　　对于科技类企业对DevOps的引入实际要分两个层面来看。
　　第一类是大型科技公司或集团，互联网类公司，本身就有大量的IT技术类人员，其核心业务本身就是软件产品研发或定制，因此这里公司引入DevOps提升研发效率和自动化是自然的事情，但是这类公司大部分是自己研发。
　　第二类是很多企业在上云迁移和实施的过程中，本身在使用类似阿里云效，华为DevCloud，腾讯Coding等各种DevOps平台能力，即实施了公有云服务商的一整套DevOps解决方案。DevOps市场发展和生态
　　DevOps理念由来已久，其在2009年被正式提出时正是云计算概念获得广泛关注的时间，然而一直以来全球范围内的软件 企业虽然有实践DevOps的意愿，却缺乏相应的技术和工具。2013年末Docker容器引擎开源，随后容器编排工具K8s逐步获得市场认可，通过容器镜像对应用程序进行标准化的封装和编排成为软件研发行业新一代的主流架构。
　　云原生技术中的容器和微服务架构的天然契合加速了对传统巨石架构的颠覆，软件内部架构的解耦也使得践行DevOps方法和流程成为可能。可以认为 docker容器的问世和推广为DevOps的发展打下了技术基础。
　　简单来说还是微服务和容器云发展进一步推动了DevOps的发展。
　　也就是说一个企业还是传统单体架构，也没有实施容器云平台，那么这种场景下很可能不需要DevOps，一般来讲实施简单的持续集成方法论即可解决问题。
　　微服务和容器云让传统架构的集成和交付过程变复杂了，工作量也剧增，这是导致DevOps支撑快速发展的一个重要推动力。
　　随着云原生整体的快速发展，持续集成和持续交付也成为了云原生的核心要素，因此可以看到公有云服务厂商为了将其云服务能力从资源层提升到服务层，从公有云延伸到内部私有云，从运行运维态延伸到开发态，也不遗余力的推送DevOps研发平台，持续集成交付平台的推广。
　　要让企业从长在云上变化为生在云上，从云原生1.0变化到云原生2.0，那么DevOps支撑类平台的实施将是一个重要的抓手。
　　由于DevOps的复杂性和灵活性，全球IT领域尚未对DevOps的规范达成一致。2013年OASIS推出的TOSCA（云应用程序 的拓扑编排规范）响应了DevOps的开发方法，大多基于TOSCA的云编排软件平台如Cloudify都支持DevOps。
　　2018年4月， DevOps标准项目——＂研发运营一体化能力成熟度模型＂在中国通信标准化协会立项成功，随后中国信通院逐步对该模型 型进行了完善和评估，目前已经发布整体架构、敏捷开发过程、持续交付过程、技术运营、组织架构等部分。DevOps在 我国的行业规范逐步建立，为DevOps平台提供商不断提高DevOps服务能力提供了规范化指导，有利于我国DevOps产业 的健康发展以及应用市场的持续增长。
　　对于DevOps成熟度模型介绍可以参考：
　　从敏捷开发到持续交付-DevOps成熟度模型解析
　　DevOps支撑工具链
　　对于DevOps工具链，更多是各种开源类工具的一个集成，以服务软件从代码管理到编译构建，部署，测试，交付，运维的全生命周期管理。
　　在这里只说下当前我们项目本身应用的主流工具链研发管理：禅道开源版本微服务框架：SpringCLoud代码库：GitLab持续构建+集成：Maven+Jekins制品库：JFrog自动化测试+静态检查：Sonar，Python容器云：Kurbernetes+Docker监控运维：Zabbix+Skywalking+ELK
　　如果从云原生角度，当前有个重点就是基于ServiceMesh的去中心化的微服务治理，这个也是我后续准备实践的关键内容，同时将Mesh框架和DevOps过程进行整合，并在应用和服务层启用普罗米修斯进行监控。
　　DevOps市场规模分析
　　未来5年DevOps市场复合增长率将超过25%。
　　随着互联网转型的深入，目前各行业的头部企业基本都已经开始了DevOps转型实践，并形成了良好的带头和示范作用， 未来数年DevOps工具将继续向企业渗透，并保持稳定的市场规模的增长。预计2020年年底DevOps市场规模将达到27亿元，5年之后这一市场将增长至83亿元，复合增长率将超过25%。
　　注意这个市场规模估算偏大，单纯狭义的DevOps很难达到这个市场规模。更多的还是包括了容器云平台，敏捷研发管理平台，自动化测试工具，云原生整体技术解决方案和咨询规划实施等内容。
　　DevOps当前很多大企业都在自研，实际很难纳入到市场规模里面。
　　从私有云市场，企业本身的DevOps实施这块来看，可以看下润和软件，普元，博云，蓝鲸这几个大点企业来说，整体DevOps营收预估最多是5到10亿的规模。DevOps技术发展趋势
　　对于DevOps支撑平台或研发运维一体化解决方案可以看到很多企业都在推，在这里我说一个总结性的说明。
　　对于公有云服务厂家，类似阿里云， 华为云，最早仅仅是做容器云PaaS平台，但是逐步延伸到DevOps和研发过程管理平台，包括阿里的云效，华为的DevCloud平台等。
　　开源的工具厂家也分别在推自己的DevOps平台和解决方案，其中类似Git推出自己的GitOps解决方案，Jekins推出自己的围绕CI/CD为核心的DevOps平台，JFrog虽然核心是制品库，但是也推出了自己的DevOps完整解决方案和平台。而红帽在收购了Ansible后围绕自动化运维推出自己的DevOps解决方案。还有就是类似传统的研发管理平台厂家本身也在向DevOps能力延伸，比较典型的就是Coding，最终仅仅是做敏捷研发和过程管理，当前过渡到完整的DevOps能力支撑平台。
　　还有大量IT发展相对成熟的大企业个，更多的是基于各自开源工具链自主研发自己的DevOps支撑平台，这些主要集中在电信，电网能源，金融银行等行业为主。
　　云平台+开源软件是主流的DevOps平台构建方法
　　由于主要国际开源社区如CNCF、Apache均有着了大量涉及DevOps的项目， 具备相关专家人才和技术积累的企业也可能选择将主流的版本控制、构建等工具集成为DevOps流水线，能够以较低的成本满足企业基本的开发运维需求。
　　对DevOps流程上各环节所用的软件工具均进行独立的开发再集成为一体化的DevOps平台 是极少数国际IT巨头企业的选择。由于主要开源工具经过多年市场验证广受认可，一般而言可以以插件的形式接入IT 厂商提供的DevOps平台，使开发者能继续使用长期以来习惯的工作环境，也是目前国内主流的DevOps构建方法。
　　实际可以看到商用DevOps平台不会是一个主流，更多的还是开源化+定制化，也就是说企业在实施DevOps的是一定希望是自主可控，而不是又购买一个商用软件。基于开源工具链定制部分的代码也必须全部开源给企业。
　　因此DevOps实施更大的价值已经不再提供一个平台化的产品，而是前面谈到的微服务+敏捷研发+持续集成的核心思想和最佳实践的传递。
　　包括在报告里面也提到了培训+咨询实施是协助DevOps转型和落地的一个关键。在前面文章里面我们也谈到了，远行科技当前本身可以提供完整的微服务架构转型，DevOps实施落地的架构咨询和方案规划服务。
　　对于整个DevOps发展方向，个人提出以下几个关键点。
　　多云管理将成为一个关键趋势
　　前面已经谈到了公有云服务厂商本身也在推DevOps，但是这个DevOps是公有云服务，本身不会在企业内部私有部署，如果要用这个服务，那么企业所有的研发环境，测试环境必须全部迁移上云，但是这个本身必要性不大。
　　更好的方法是企业研发，测试环境在私有云，而部分对外提供能力的生产环境在公有云。
　　那么这个时候就涉及到私有云和公有云的混合管理能力。
　　也就是说通过DevOps来衔接内部私有云和外部公有云，实现软件应用的跨云持续交付能力，跨云融合管理能力。
　　从DevOps到AIOps智能化运维
　　对于智能化运维我在前面专门写过文章，这个实际是DevOps发展的一个延伸。
　　在DevOps成熟度模型里面就可以看到从运维管理提升到了技术运营这个概念，其核心意思就是在整个研发运维一体化过程中，运维人员将变化为数据驱动，监控驱动的运营人员；从被动的问题驱动变化为主动的风险驱动，主动去发现风险并减缓风险。
　　也就是说运维过程本身推动软件的持续改进过程，运营或运维人员反而变成了一个主导地位。而要做到这点，里面核心的就是从自动化运维发展到智能化运维。
　　从DevOps到DevSecOps
　　DevSecOps的理念是将安全防护流程有机地融入传统的DevOps流 程中，通过自动化、智能化的方法使其成为软件开发和运维中的内生部分，以统一的流程实现对安全防护的兼顾。在云原 生时代，安全策略在全球范围内受到的重视越来越高，软件开发内生安全性将成为评价企业DevOps成熟度水平的重要指标。
　　在 DevOps协作框架下，安全防护是整个 IT 团队的共同责任，需要贯穿至整个生命周期的每一个环节。
　　DevSecOps 强调在 DevOps 计划刚启动时就要邀请安全团队来确保信息的安全性，并制定自动安全防护计划，实现持续 IT 防护。它还强调，要帮助开发人员从代码层面确保安全性；在这个过程中，安全团队需要针对已知的威胁共享掌握的全局信息、提供反馈并进行智能分析。
　　对于DevOps安全防护，可以看到从最早的代码安全性检测，漏洞扫描，代码规范性检查等，已经发展到了和容器云平台的安全融合，即很多容器云安全的内容也可以内置到整个DevOps流水线设计中，尽量在前期的开发和测试阶段就发现相应的安全性问题并有针对性的解决。
　　进一步和ServerLess和低代码开发融合
　　在前面讲DevOps的时候曾经谈到过，一个应用开发本身涉及到了数据库和应用中间件两个部分的内容，实际在当前大部分的DevOps中都不能很好的实现数据库本身的自动化部署和弹性扩展。
　　数据库本身还对应的是资源层能力，而部署包对应的是PaaS服务层能力。
　　要完全地实现DevOps，就需要所有应用涉及到的基础能力都由资源层转移到服务层，不是使用资源，而是使用技术服务。类似我们谈ServerLess的时候也在谈，只有当底层的BaaS服务能力足够强大的时候，上层应用才是能够实现低代码开发。
　　因此在ServerLess和低代码平台发展过程中，完全可以和DevOps持续集成和交付过程融合。简单来说就是：
　　首先提供一个基础的平台层能力和共性的业务平台，但是本身这个平台是开放的，所有能力都通过API服务的方式暴露出来，上层应用可以基于服务快速的开发，在开发完成后，整个编译构建，打包部署过程完全的自动化。即整个开发过程实现自动化的交付能力。
　　如果整个开发IDE环境都不在桌面端，那么整个过程就可以完全在云端实现基于低代码开发思路下的完整持续集成和持续交付过程。
　　欢迎关注@人月聊IT， 分享云原生，微服务，数字化转型，思维类文章。公众号同名，周一，三，五更新。网上无法下载需要改报告的也可以关注后给我私信。