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

一、背景

随着架构的不断演进以及微服务技术在我行的深入应用,应用部署发布的复杂性大大增加,简单的代码配置管理模式、人工的版本记录及手工部署等发布操作和管理的模式,效率低、操作风险较大,因此急需从整体上提升我行软件持续交付的能力,降低应用部署发布的操作风险。
通过引入构建自动化及可视化的软件交付流水线,整合从开发、构建、测试、部署、发布、运维等多个环节,加强各职能团队协助和沟通,全面实现项目构建持续自动化管理。

二、实施方法

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等工具,提升编译速度和增强资源的灵活调度能力,将持续集成的完整链路打通,示例如下:

4. 持续部署

软件团队通常需要将发布后续推送到不同部署环境进行上述讨论的不同类别的测试。
例如,常见的情况是将软件部署到测试环境进行人为的质量检查测试,然后部署到性能测试环境,进行自动化负载测试。 如果构建通过该测试阶段,则应用程序可能稍后部署到用于 UAT 或 beta 测试的独立环境中。
理想情况下,将任意发布候选制品以及与之通信的其他系统可靠地部署到任意环境中的这个过程应尽可能实现自动化。
如果企业希望按照计划的速度持续交付,那可能需要每天或每周多次执行,因此它的工作速度和可靠性至关重要。
用自动化方式在环境之间移动软件是作为DevOps的团队的主要特性之一,因此这也是DevOps的关键重点。
示例如下:

5. 技术架构

6. 技术、工具、角色、能力梳理

Devops实施时,涉及到的技术、工具、角色、能力梳理如下:

三、收益

一期完成了Jfrog制品库采购、上线、高可用建设并围绕Jfrog制品库进行了工具链的打通;实现了持续集成与持续部署功能、制品提升功能、软件包不同仓库流转功能、软件包依赖关系管理、软件包元数据可视化管理及试点项目的接入;
主要得到的收益如下:
统一制品库管理:软件包统一由制品库管理,改变原来散落在各处,无法跟踪追溯的问题。
简化操作步骤:使用前,开发人员部署需要手工操作7-10步;使用后,可以一键部署到DEV、SIT、UAT等环境。
缩短等待时间:测试人员可按需部署,无需等待。改变了以往测试人员需等待开发人员部署的情况。

**更多技术分享请关注 JFrog杰蛙在线课堂
1月7日,20:00 在线课堂:《Netflix,甲骨文的 DevOps 之路》
课堂收益:

  1. 介绍甲骨文在进行 DevOps 变革时遇到的困难
  2. 解决办法
    3.落地 DevOps 用到的工具链
    4.甲骨文的自助式 CI/CD 平台
    5.Netflix的持续交付平台 Spinnaker
    6.完成 DevOps 转型之后得到的收益
    报名链接:https://www.bagevent.com/event/6321621
    抽奖活动:
    课堂结束前五分钟,进行抽奖活动
    第一名:小米蓝牙耳机
    第二名:JFrog杰蛙新版T恤
    第三名:JFrog杰蛙新版T恤
    **

原文地址:https://blog.51cto.com/jfrogchina/2464727

时间: 2024-08-25 22:55:55

[首发]国内某大型银行的持续集成与交付实践的相关文章

持续集成与自动化部署 - dev ops & 持续集成、交付、部署 介绍 (三)

1 什么是devops DevOps是一种文化,让开发.测试.运维之间沟通的文化. 过程.方法.系统的统称.目标:让软件从构建,开发,测试,上线,更加的快捷 安全的上线. 列如saltstack他就是一个devops的工具.自动话测试平台也是devops 2 持续集成.交付.部署介绍 2.1 继续集成 在软件开发的过程中,频繁的将代码集成到主干上,然后进行自动化测试. 2.2 持续部署 持续交付是指在持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-

美团点评:打造微服务自动化测试与持续集成工具链实践

本文内容节选自第六届全球软件案例研究峰会,时任美团点评酒旅质量团队工具链负责人王鹏老师分享的<微服务架构下的自动化测试和持续集成工具链实践>实录,重点分享:微服务架构下解决自动化测试.开发联调.测试环境.持续集成方面遇到的问题及解决方案.(PPT+文稿). 王鹏老师时任美团点评酒旅质量团队工具链负责人,在软件开发,自动化测试,研发流程改进,持续集成/交付基础设施,敏捷开发等领域有近10年的开发实施和推广经验. 编者按:2017年11月9-12日,第六届全球软件案例研究峰会在北京国家会议中心盛大

研发协同平台持续集成之Jenkins实践

导读 研发协同平台有两个核心目标,一是提高研发效率 ,二是提高研发质量,要实现这两个核心目标,实现持续集成是关键之一. 什么是持续集成 在<持续集成>一书中,对持续集成的定义如下:持续集成是一种软件开发实践.在持续集成中,团队成员频繁集成他们的工作成果,一般每人每天至少集成一次,也可以多次.每次集成会经过自动构建(包括自动测试)的检验,以尽快发现集成错误.自从在团队中引入这样的实践之后,Martin Fowler发现这种方法可以显著减少集成引起的问题,并可以加快团队合作软件开发的速度. 1.集

持续集成之jenkins实践教程 基础篇 4 集成redmine

作为持续集成的利器Jenkins已经得到了广泛地应用,仅仅作为一个工具,Jenkins已然了了自己的生态圈,支持其的plugin更是超过1300+.在实际中如何使用以及如何更好地使用jenkins,一直是大家在实践并讨论的.本系列文章将会从如何使用jenkins方面对一些细节进行总结和整理,这篇文章将会介绍如何在Jenkins中实现与redmine的集成 事前准备 只要有jenkins即可,没有的可以使用Jenkins官方的镜像或者安装包,或者使用Easypack中封装的基本一致的Jenkins

Gitlab CI 持续集成的完整实践

本着公司团队初创,又在空档期想搞点事情,搭建了私有Gitlab的契机,顺便把持续集成搭建起,实现了对Python服务端代码的单元测试.静态代码分析和接口测试的持续集成.总体架构如下: 执行过程: 开发提交代码后,自动触发gitlab-runner拉取executor镜像执行单元测试,单元测试代码中包含上传测试结果到x-utest测试平台: 单元测试通过后,gitlab-runner拉取sonar-scanner镜像执行静态代码分析,分析结果评论在commit中或保存于sonarqube: 静态代

持续集成方案

大纲 构建 版本控制 部署 单元测试 架构文档化 命名约定 数据库伸缩性 自动化 反馈 实践 引言: 持续集成的前身: 在使用持续集成之前,很多开发团队都是用每日构建(nightly build).当时,微软使用这个实践很多年了.谁破坏了构建,就要负责监视后续的构建构成,直至发现下一个破坏了构建的人. 为什么要使用持续集成? 对于大多数项目来说,采纳持续集成实践是向高效率和高质量迈进的一大步.它保证那些创建大型复杂系统的团队具有高度的自信心和控制力.一旦代码提交引入了问题,持续集成就能为我们提供

&lt;转&gt;about持续集成,你不知道的事

从别处看到了一篇关于持续集成的文章,个人感觉蛮不错的,分享给大家... 原文链接:对于持续集成实践的常见问题解答 1.什么是持续集成? 集成,就是一些孤立的事物或元素通过某种方式集中在一起,产生联系,从而构成一个有机整体的过程.知识经济的社会,集成已经成了很重要的一个名词.各行各业基本都会用到集成. 而在软件行业中,集成并不是一个简单的"搬箱子"的过程.因为软件工业是一个知识生产活动,其内在逻辑非常复杂,需求又很难一次性确定,完成的产品与最初的设计往往相差很远. 敏捷宣言中就有一条是说

Azure云中Web应用的持续集成实践

由于从事的工作领域关系,目前会或多或少的关注DevOps课题的相关领域,当然目前还在尝试多种适应于持续开发持续集成领域的工具和组合方式,个人粗浅的领会是DevOPS其实既不会只是开发者需要关注的,也是运维人员应该关注的领域,因为未来的IT世界其实是个"相对混合"的空间,发展之快超出想象:在开发测试领域的工具上看,Chef/Puppet/PowerShell DSC,到开源领域广泛应用Salt Stack, Ansible到 Docker生态圈等封装一系列基础架构即代码等概念的涌现,无时

为什么我们迫切需要持续集成(Continuous Integration)

原文同步至 https://waylau.com/why-we-need-continuous-integration/ 持续集成(Continuous Integration),也就是我们经常说的 CI,是现代软件开发技术的基础.本文论述了当前软件开发过程中存在的问题,讲解了持续集成.持续集成服务器的概念,最终探讨了为什么我们需要持续集成来解决这些问题. 当前软件开发过程存在的问题 在没有应用持续集成之前,传统的开发模式是这样的: 项目一开始是先划分好模块,分配模块给相应的开发人员: 开发人员