当前位置：首页 > news >正文

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

news 来源：原创 2025/8/25 11:03:55

摘要：

随着互联网的不断发展，各行各业都在建设自己的企业信息系统，而随着业务的不断升级和复杂化，系统的更新迭代速度越来越快，系统也越来越复杂。对于信息系统开发者，架构师，管理者，如何高效的开发，集成，交付高质量的系统功能成了系统开发者，架构师，管理者们的一项具有挑战性的工作。在不断的实践经验中，我们总结了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 等）进行结合，生成部署计划，一键执行自动化部署。

运维阶段：对于已部署的实例进行运维管理，包括启动、停止、重启、修复、状态检查等等。

持续交付流水线

运维阶段：对于已部署的实例进行运维管理，包括启动、停止、重启、修复、状态检查等等。

持续交付流水线

为什么需要持续交付流水线？举个例子来说，我们常常苦恼最终上线版本和系统集成测试环境不一致。这一般是因为在系统集成测试完成后发现了问题，作了代码变更但没有重新构建，而是直接在介质里进行了调整进而发布上线。在持续交付流水线中是不允许这种情况出现的。所有上线入口一定是最初的构建，所有的后续产物都是基于这一介质，如果有变更必须重走流程。这样可以保证发布的安全性和统一性，线上出现问题也是可以追溯的。当然过程中的环境可以配置人工介入或自动执行。

发布流水线从构建到生产部署共 9 大环节，涵盖 SIT/UAT/LAB/PROD 四大环境。驱动了开发、测试、质量、运维等多个角色的协作。

在设计流水线能力时，我们主要考虑到几点：

结合企业的不同交付流程，要能支持自定义的流程配置，要能支持多套流程配置

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

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

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

要有一个看板，直观的看到整个产品的版本目前到了流程的哪个环节，是 SIT 还是 UAT，结果如何

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

以这些为基础准则，我们底层基于了我们的 BPS 流程引擎，支撑流程的自定义和扩展。并且，针对于每个环节，都可以配置前置后置事件、人工执行还是自动执行，责任人等。整个流水线从构建开始，保证全局介质唯一，避免人为修改介质导致的生产介质不可追溯。

度量优化

精益运营的基础是度量，度量的三大维度：指标、执行监控、预测。首先是明确指标和执行监控，基于软件全生命周期的度量过程中企业遇到的最大困难莫过于拿不到完整的数据，各个部门、各个流程、各个系统之间数据相互隔阂，信息很难流通，导致无法从整体的角度对软件过程进行度量。当 DevOps 平台能打通企业的软件生产全生命周期时，数据的割裂性问题自然也就不存在。当然，度量不仅仅是事后的统计分析，更应该提供过程监控的能力，在过程中，通过一些看板（比如任务看板、需求看板、发布看板）、趋势图（比如任务燃尽图、bug 燃尽图）等，提前预知风险，规避风险，持续把控项目质量和产品质量。

总结

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

摘要：

背景：

正文

总结

相关文章：