【软考】论devops在企业信息系统开辟中的应用

摘要：

      随着互联网的不绝发展，各行各业都在创建自己的企业信息系统，而随着业务的不绝升级和复杂化，系统的更新迭代速率越来越快，系统也越来越复杂。对于信息系统开辟者，架构师，管理者，怎样高效的开辟，集成，交付高质量的系统功能成了系统开辟者，架构师，管理者们的一项具有挑战性的工作。在不绝的实践履历中 ，我们总结了devops方法，可以或许快速 进行系统开辟，系统集成 ，系统交付，从而缓解了企业对系统创建快速交付的要求，该套方法介绍系统开辟中怎样应用devops进行系统快速开辟，持续集成，快速交付的方法和工具
背景：

 本人  ，作为公司的系统架构师，有幸参与了公司的信息化系统的架构，管理，全面管理工作。现在我以系统“XXX全息系统”为例介绍devops在企业信息系统开辟中的应用。
正文

从逻辑上把 DevOps 平台分别为三大范畴：敏捷过程、持续交付、持续改进。敏捷过程针对于软件过程进行管理，包罗产品、项目、团队、筹划、任务等，持续交付则关注从需求到上线交付的管理，包罗持续集成、自动化测试、自动化摆设、交付流水线等。持续改进则体现了平台的核心代价，不绝的度量和优化软件过程，为提升 IT 运行效率打下坚实的基础
DevOps 平台分别为范畴层、基础服务层、工具层三层。工具层封装了一些开源工具，提供基础本领。服务层在此基础上封装的一些基础服务，如编译、摆设、代码管理等。范畴层主要包罗项目管理、产品管理、构建、摆设、交付流水线、度量优化等模块。底层运行情况支持物理机、虚拟机、容器云平台。
软件的整个生命周期可以从不但仅是项目标生命周期，而是应该也包罗了产品的生命周期。在企业内部，通常我们先决定做哪个产品，然后需求调研、版本分别，确认了具体版本要实现的需求范围后，便可以组建项目进行研发。研发完成进行交付后，有进入产品的线上运营阶段。直至产品下线。一个产品可以对应多个项目，固然，对于有些企业而言，一个项目也是持续稳固的维护一个产品。
持续集成

持续集成模块功能主要有代码库管理、构建定义管理以及构建实例管理等。在构建定义管理模块中，DevOps 平台将构建任务分成了四种范例：

• 编译类任务：Maven、Ant、Gradle、纯前端构建等
  

• 测试类任务：Sonarqube、Jmeter、Selenium等
  

• 打包类任务：Npm、Archive、Docker 等
  

• 其他工具类任务：Copyfile、Shell、介质提交到Nexus 仓库、介质上传二方库等。
  

在每个构建定义上可以选择若干个需要的构建任务，通过原子步调编排，组装成一个完备构建流程。代码提交时触发构建（支持 gitlab、github、svn 等常用代码库版本管理工具）、日构建等差别的构建触发计谋等支持了持续集成的完备链路打通。
自动化摆设
在自动化摆设模块中，为了更好的与实际联合，我们将摆设分为三个阶段：计划、转换、运维。
计划阶段： 将摆设架构分为三层：摆设装配（Assembly）、摆设容器（Platform）、摆设组件 (Component)。摆设装配是对摆设架构的描述，由多个摆设容器构成，每个摆设容器由若干个摆设组件构成。
转换阶段： 将摆设架构与摆设计谋（全新、蓝绿、灰度、滚动升级等）、资源（具体资源如物理机、虚拟机、容器）、组件配置参数（端口号、JVM 参数、健康查抄 url 等）进行联合，天生摆设筹划，一键执行自动化摆设。
运维阶段： 对于已摆设的实例进行运维管理，包罗启动、制止、重启、修复、状态查抄等等。
持续交付流水线
计划阶段： 将摆设架构分为三层：摆设装配（Assembly）、摆设容器（Platform）、摆设组件 (Component)。摆设装配是对摆设架构的描述，由多个摆设容器构成，每个摆设容器由若干个摆设组件构成。
转换阶段： 将摆设架构与摆设计谋（全新、蓝绿、灰度、滚动升级等）、资源（具体资源如物理机、虚拟机、容器）、组件配置参数（端口号、JVM 参数、健康查抄 url 等）进行联合，天生摆设筹划，一键执行自动化摆设。
运维阶段： 对于已摆设的实例进行运维管理，包罗启动、制止、重启、修复、状态查抄等等。
持续交付流水线
为什么需要持续交付流水线？举个例子来说，我们常常苦恼终极上线版本和系统集成测试情况不一致。这一般是由于在系统集成测试完成后发现了题目，作了代码变更但没有重新构建，而是直接在介质里进行了调整进而发布上线。在持续交付流水线中是不允许这种情况出现的。全部上线入口肯定是最初的构建，全部的后续产物都是基于这一介质，如果有变更必须重走流程。这样可以保证发布的安全性和统一性，线上出现题目也是可以追溯的。固然过程中的情况可以配置人工参与或自动执行。

发布流水线从构建到生产摆设共 9 大环节，涵盖 SIT/UAT/LAB/PROD 四大情况。驱动了开辟、测试、质量、运维等多个角色的协作。
在计划流水线本领时，我们主要考虑到几点：

• 联合企业的差别交付流程，要能支持自定义的流程配置，要能支持多套流程配置
  

• 流程的每一个环节都要支持自动执行的配置
  

• 流程中每个环节的属性和配置信息可以自定义，灵活扩展
  

• 流程以构建开始，让 buildNumber 贯穿整个流程，方便追根溯源
  

• 要有一个看板，直观的看到整个产品的版本现在到了流程的哪个环节，是 SIT 照旧 UAT，结果怎样
  

• 要有一个看板，直观的看到每个情况下，有哪些介质在运行
  

以这些为基础准则，我们底层基于了我们的 BPS 流程引擎，支持流程的自定义和扩展。并且，针对于每个环节，都可以配置前置后置事件、人工执行照旧自动执行，责任人等。整个流水线从构建开始，保证全局介质唯一，制止人为修改介质导致的生产介质不可追溯。
度量优化
精益运营的基础是度量，度量的三大维度：指标、执行监控、猜测。首先是明确指标和执行监控，基于软件全生命周期的度量过程中企业遇到的最大困难莫过于拿不到完备的数据，各个部分、各个流程、各个系统之间数据相互隔阂，信息很难流通，导致无法从整体的角度对软件过程进行度量。当 DevOps 平台能打通企业的软件生产全生命周期时，数据的割裂性题目自然也就不存在。固然，度量不但仅是事后的统计分析，更应该提供过程监控的本领，在过程中，通过一些看板（比如任务看板、需求看板、发布看板）、趋势图（比如任务燃尽图、bug 燃尽图）等，提前预知风险，规避风险，持续把控项目质量和产品质量。
总结

我们在创建过程中，每一个模块都需要联合万达的流程规范以及我们的最佳实践共同进行创建，在前期，当一些流程规范不是那么明确的时候，还需要一起讨论，同时规范也不是一蹴而就的，实施过程中发现一些不符合的地方就需要进行修改，这也就带来了需求的反复的可能。以持续交付流水线为例，这个就需要联合万达的情况、发布规范来定制流程，对于其他企业而言，持续交付流水线未必就是这样的一个流程，有可能会少一些情况，也有可能多个预发情况，又大概会把这一个流水线拆分成多个流水线。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。