国内某大型银行的持续集成与交付实践

一、背景 随着架构的不断演进以及微服务技术在我行的深入应用，应用部署发布的复杂性大大增加，简单的代码配置管理模式、人工的版本记录及手工部署等发布操作和管理的模式，效率低、操作风险较大，因此急需从整体上提升我行软件持续交付的能力，降低应用部署发布的操作风险。 通过引入构建自动化及可视化的软件交付流水线，整合从开发、构建、测试、部署、发布、运维等多个环节，加强各职能团队协助和沟通，全面实现项目构建持续自动化管理。 二、实施方案 1.总体框架 DevOps是一组能够帮助软件开发团队极大的提高其软件交付的速度和质量的模式和最佳实践组成；DevOps的整体架构如图：  从使用层次主体关联：开发、测试和运维团队，配套对应的权限控制体系。 从交付流程方面：涵盖从代码到应用交付的全流程管理。 DevOps平台既包括了项目管理、产品管理、交付中心、组织机构等宏观维度的各项，同时在也纳入了编译、部署、代码管理及pass平台部分，同时，平台机制应该支持灵活的扩展（如工具集成扩展、部署能力扩展等），面对复杂的场景或者特殊需求的时候，平台也可以提供更加灵活的能力。 2.功能介绍 功能将实现流水线管理、质量管理、告警管理、制品管理、项目信息管理、系统管理、个人工作台等模块，达到交付自动化，可视化的目标。 3.持续集成 持续集成模块功能主要有代码库管理、构建定义管理以及构建实例管理等，DevOps平台中构建任务可以分为以下类型： · 需求类任务：jira、ones等 · 编译类任务：Maven、Ant、前端构建等 · 打包类任务：Maven 、ant、gradle、npm、docker等 · 测试类任务：junit、Postman、Jmeter等 · 静态代码扫描：Sonarqube · 安全扫描：Xray · 部署类任务：ansible、chef、shell · 容器类：k8s、mesos · 日志类：elk · 其他工具类任务：shell、制品提交到nexus仓库、Jfrog制品库等。 每个构建定义上可选择若干个需要构建的任务，通过原子步骤编排，组装成一个完整的构建流程，代码提交时触发构建（支持gitlab、github、svn等常用代码库版本管理工具），结合诸如jenkins、docker等工具，提升编译速度和增强资源的灵活调度能力，将持续集成的完整链路打通，示例如下： image002.png {{image003.png(uploading...)}} 4. 持续部署 软件团队通常需要将发布后续推送到不同部署环境进行上述讨论的不同类别的测试。 例如，常见的情况是将软件部署到测试环境进行人为的质量检查测试，然后部署到性能测试环境，进行自动化负载测试。如果构建通过该测试阶段，则应用程序可能稍后部署到用于 UAT 或 beta 测试的独立环境中。 理想情况下，将任意发布候选制品以及与之通信的其他系统可靠地部署到任意环境中的这个过程应尽可能实现自动化。 如果企业希望按照计划的速度持续交付，那可能需要每天或每周多次执行，因此它的工作速度和可靠性至关重要。 用自动化方式在环境之间移动软件是作为DevOps的团队的主要特性之一，因此这也是DevOps的关键重点。 示例如下： {{image004.png(uploading...)}} 5. 技术框架 {{image005.png(uploading...)}} 6. 技术、工具、角色、能力梳理 Devops实施时，涉及到的技术、工具、角色、能力梳理如下： {{image006.png(uploading...)}} 三、收益 一期完成了Jfrog制品库采购、上线、高可用建设并围绕Jfrog制品库进行了工具链的打通；实现了持续集成与持续部署功能、制品提升功能、软件包不同仓库流转功能、软件包依赖关系管理、软件包元数据可视化管理及试点项目的接入； 主要得到的收益如下： 统一制品库管理：软件包统一由制品库管理，改变原来散落在各处，无法跟踪追溯的问题。 简化操作步骤：使用前，开发人员部署需要手工操作7-10步；使用后，可以一键部署到DEV、SIT、UAT等环境。 缩短等待时间：测试人员可按需部署，无需等待。改变了以往测试人员需等待开发人员部署的情况。