在碰撞中成长 – 北京银行的DevOps实践之路

0
139

2018年10/27日,在上海召开的微软年度最大规模的技术盛会—微软2018技术暨生态大会上,北京银行渠道系统负责人&敏捷团队负责人周兵女士和大家一起分享了北京银行的DevOps 实践转型经验,得到了大会听众的热烈评价和共鸣,会后众多金融和互联网行业的客户意犹未尽,还和周兵女士进一步探讨DevOps转型的经验。

嘉宾简介


周兵- 北京银行渠道系统负责人&敏捷团队负责人

演讲实录

下面是我们现场收集的周兵女士演讲内容,快速整理记录如下,弥补大家不能到现场交流探讨的遗憾;不过还是建议大家下次来现场哦,现场气氛真的是热烈。

微软Azure DevOps在北京银行的实践

大家好,非常荣幸能够在微软技术暨生态大会上和大家分享北京银行进行敏捷与DevOps转型的实践经历和经验。

北京银行成立于1996年,是一家新型的股份制商业银行,拥有近620家分支机构,价值排名中国区域性发展银行首位,一级资本排名全球千家大银行63位,连续五年跻身全球银行业百强。近两年,北京银行积极探索数字化转型,并以打造金融科技型银行作为全行转型突破口。其中,提升敏捷服务能力,及时响应市场需求,是转型过程中最迫切的需求之一。在此背景下,我行开启敏捷转型探索之路,并于2017年6月,引入微软研发管理平台Azure DevOps Server,作为敏捷落地工具。

银行做敏捷,与互联网行业做敏捷不同:首先,银行业是强监管、重流程的行业,所以,银行做敏捷,要求的是在稳定运行、杜绝风险的基础之上的敏捷。第二,银行系统多,有渠道类、账务类、支付类、数据类、总线类系统,系统类型之间所适应的模式也不同,所以,银行做敏捷,要求的是稳态与敏态共存的敏捷。

在试点之初,我们也存在着诸多困惑:北京银行与微软Azure DevOps Server如何进行基因适配?利用Azure DevOps Server推行敏捷是否有统一的范式?我们的转变应该是一步到位还是渐进式改革?这些问题随着我们的探索与实践逐渐清晰,一起来看看我们的实践之路。

敏捷初衷——我们为何转变?

在传统的工作流程中,存在着诸多的痛点,比如:

  • 项目多,投产次数多,其中以手机银行为代表的渠道类系统最为突出。
  • 环境多,版本管理较复杂,其中以ESB为代表的总线型系统最为突出。
  • 项目流程繁琐,一个项目从立项到投产,大概需要15个环节,每个环节有相应的文档要求,整个过程需要提交多个文档,且需要在多种不同的系统中进行操作。

总体上,存在系统之间相对独立,形成信息孤岛的问题,很多流程仍依赖于线下沟通和手工操作,使得我们难以用有限的开发资源,更好地满足日益增多的业务需求和日益增强的监管要求。

因此,我们希望能有一套平台,对项目流程进行全生命周期的管理,以实现有效的协作研发:

  • 针对项目多,投产次数多的现状,实现自动化集成部署的流水线;
  • 针对环境多,版本管理较复杂的现状,实现清晰灵活、自动化的版本管理;
  • 针对项目流程繁琐、文档多、系统多的现状,实现开发流程的统一化及项目管理的精细化。

而微软的TFS(Team Foundation Server,现已更名为Azure DevOps Server)正是这样一套平台,集项目管理、版本管理、持续集成、持续发布和测试管理为一体,其中,项目管理和测试管理是项目维度的,版本管理、持续集成、持续发布是系统维度的。我们通过引入TFS这一有力工具,探索实现对项目的全生命周期管理和基于敏捷与DevOps的协作研发机制。

基因适配——我们在碰撞中成长

我们选取了不同类型的系统团队进行试点,在实际试用过程中,遇到多种困难,我们归结为两大碰撞:一是TFS理想化的全生命周期管理与实际项目过程中错综复杂、系统多样化的种种现实的碰撞;二是TFS基于敏捷、设计灵活的使用方式与实际项目过程中期望简洁、并与现有流程完美契合的碰撞。

具体来说有三个问题:

  1. 项目管理:如何简便、清晰地区分项目维度与系统维度的交叉?
  2. 版本管理:如何做好多项目并行、投产时间不定的版本管理?
  3. 测试管理:如何在测试管理阶段做到既实用又满足监管要求?

两大碰撞的根本原因,是TFS基于敏捷迭代、强调协作的设计理念与银行强监管、重流程的工作理念之间的碰撞。试用过程是通过发现问题、解决问题、探索方案,分析定制化可行性等措施,着力解决两大碰撞的过程,是在碰撞中成长,通过基因适配,探索北京银行基于TFS的最佳实践的过程。

第一:项目管理

首先,关于项目维度与系统维度的交叉,我们在TFS中建立“项目管理”的团队项目,自动从行内项目管理系统同步需求,同时,建立全行系统清单,每一个系统在TFS中为一个团队项目,两者通过需求进行关联,形成清晰灵活、满足各个维度管理要求的规范流程。

第二:版本管理

关于版本管理,我们直接选用GIT分支型的版本管理,并按照即有版本管理要求,划分为开发库、受控库和产品库,分别对应开发流程、准生产流程和投产流程,每一个阶段都以项目映射分支的方式进行管理。并且向前衔接需求,向后衔接测试,打通计划与交付,形成部署流水线。

第三:测试管理

关于测试管理,我们沿用了已有测试管理系统进行测试计划、测试案例、测试报告的管理,同时与TFS进行打通,将缺陷流转至TFS,保证开发人员可以在TFS中专注于需求开发和缺陷解决两个关键任务。

实践总结——我们的特色之路

北京银行基于TFS的敏捷实践,有以下几个特色点:

1. 稳态与敏态共存的双模IT

TFS敏捷实践是在我行树立“移动优先”战略的背景之下开展的,我们以移动为触点拥抱互联网,以移动为试点实践新模式,以移动为焦点不断发现问题改进流程。在这个过程中,以手机银行为代表的移动端应用处于敏态,实现了每周投产,传统的中后台系统处于稳态,仍保持双周投产。此外,“稳态”还代表了我们在践行敏捷的同时,保持原有流程不发生大的变化,兼顾效率与风险,让敏捷基因与银行“重流程、强监管”的基因进行了很好的适配。

2. 拥抱互联网兼具风险意识

我们率先采用了互联网特色的GIT分支型管理,替代传统版本管理,并设计符合监管要求的“开发库、受控库、产品库”的分支管理模式。同时,在实践过程中,我们对版本的全量发布和增量发布进行了审慎、全面的考量,我们项目组研发了增量发布插件,支持全量编译、增量发布的模式,作为对全量发布的一种补充模式,以更好地把控投产风险。

参考:

上图中提到的 Pull Request Diff Copy是 leansoftX.com 团队与北京银行合作开发的,公众号中相关文章如下。

如果需要安装此插件,请扫描上图中的二维码或者点击以下链接

https://marketplace.visualstudio.com/items?itemName=lean-soft.pull-request-diff-copy

3. 流程创新以实现自动化管理

我们组建的流程改进小组主动创新,借助TFS强大的功能,设计实现了多个自动化管理流程,比如:实现自动的代码安全扫描与加固,实现自动流转的准生产环境审批流程,实现项目文档的自动化检查,实现环境问题的自动跟踪等,通过透明化、自动化的管理,实现工作效率的大幅提升。

总结

回首实践之路,北京银行建立了一体化工具实现全流程串接,通过条目化管理实现管理粒度细化,通过数据集中实现工作即监控,通过灵活的版本管理打通计划与交付,通过自动化检查实现更有效的质量管理…让北京银行的研发管理更加统一协作、数据集中、流程规范,配置灵活和自动高效。我们还将覆盖更多角色、覆盖更多场景、进行更深度实践,沿着敏捷与DevOps之路继续前行,探索商业银行的敏捷转型最佳实践。

备注:

TFS 全称是Team Foundation Server 是微软部署在企业本地的DevOps 工具链平台;其在2019版本将更名为Azure DevOps Server. 所以在本文中Azure DevOps Server 和TFS 交替出现。

相关文章

- leansoftx.com -

发表评论

请输入评论内容
姓名