内容简介:2014年之前,SpareBank 1是在一个单体的Weblogic门户上运行其整个网络银行应用程序,每个开发人员都使用相同的代码库,发布是艰巨的过程,开发人员将他们的代码提交到整体存储库中。必须将检入代码部署到各种环境以进行集成和验收测试,还需要交付批准,同时文档必须更新。在许多情况下,审核批准周期比开发和测试阶段花费的时间更长。这意味着每年限制发布4次。2015年,该银行决定改善交付时间和效率。计划24/30的目标,这意味着:为实现这一目标,该银行做出了以下改变,即使在今天我们仍坚持:
2014年之前,SpareBank 1是在一个单体的Weblogic门户上运行其整个网络银行应用程序,每个开发人员都使用相同的代码库,发布是艰巨的过程,开发人员将他们的代码提交到整体存储库中。必须将检入代码部署到各种环境以进行集成和验收测试,还需要交付批准,同时文档必须更新。在许多情况下,审核批准周期比开发和测试阶段花费的时间更长。这意味着每年限制发布4次。
2015年,该银行决定改善交付时间和效率。计划24/30的目标,这意味着:
- 可以在24小时内完成对生产的构想
- 代码可以在30分钟内部署
为实现这一目标,该银行做出了以下改变,即使在今天我们仍坚持:
1.代码库分为可管理的块
代码被分解为微服务架构 - 将功能从Weblogic monolith移植到通过单点登录Single Sign On令牌相互通信的较小应用程序。有关详细信息,请观看Stian和Vidar的精美 JavaZone演示文稿 。
2.开发人员分为自治团队,在发布,创新和编码方面具有完全的自由。
使用 Conway康威定律 的 逆版本 ,团队根据网络银行功能切分,才能反映新的架构。每个团队都有自己的代码库,并负责自己的版本。
3.每个开发人员都使用相同的环境。
每个开发人员在同一个操作系统上使用完全相同的设置,并在同一个IDE上使用代码。
创建分支,拉取请求,合并分支与内部构建器脚本的开发一致,该脚本自动执行分支创建,Jenkins创建作业等任务。例如,使用“begin”选项运行脚本,在git上创建一个功能分支,并在构建和单元测试中创建相应的Jenkins作业。
Git钩子确保分支不能合并,除非它们通过Pull请求,并获得其他开发人员的相应批准。
批准Pull Request后,可以合并更改,并使用“complete”选项运行构建器脚本以删除功能分支和Jenkins作业。
拥有一致的开发环境可确保开发人员可以轻松地在团队之间移动,如果他们愿意的话。
4.每个应用程序共享相同的架构。
在从整体中分裂出来的20多个应用程序中,每个应用程序都具有相同的体系结构和文件结构。前端和后端目录和模块结构在不同应用程序中是一致的。
运行应用程序的框架的细节与领域代码分开。因此,如果来自其他团队的开发人员进入,框架代码已经很熟悉了。
5.有一个共同的构建过程。
每个应用程序都包含一个构建脚 由于文件结构和模块在应用程序之间是一致的,因此该构建脚本在应用程序中大致相同。还记得开发人员启动功能时由构建器脚本创建的Jenkins作业吗?所有这项工作都需要运行此构建脚本。
6.对公共库的依赖性会经常更新并自动更新。
每周更新对公共代码库的依赖性。应用程序开发人员仍必须批准Pull Requests并手动合并更改,以避免无法预料的更改,但大部分依赖项更新都是自动的。
7.一切都是自动化的!
每次提交git都会触发Jenkins构建。构建在功能分支上的是使用npm运行全套前端测试,使用jUnit运行后端测试。开发和发布分支还与Finesse一起运行集成测试。
文档现在是源代码的一部分,并在构建发布分支时构建和打包。创建发布版的开发人员必须做的唯一事情就是创建一个进入发行版的 Jira ID 列表(任务跟踪工具)。
在发布版本时,此列表将通过脚本上载到汇合,这意味着发布经理只需查看Confluence页面即可轻松查看版本中涉及的Jira ID。
如您所见,整个发布审批流程差不多已被取消。基础架构组仍需要随时了解计划发布的日期,这些版本的内容(作为Jira ID)和可能受影响的功能。这使他们为发布后可能发生的事件做好准备。
根据 Puppet的2018年DevOps报告 ,这是可以接受的:
拥有外部变更审批委员会对稳定性的影响可以忽略不计,但对敏捷性有不利影响。尽管有这些证据,但我们经常看到,做出决策的权力从拥有相关信息并正在从事实际工作的人员中删除。
8.一切都记录下来!
对后端服务的调用记录为JSON,这使日志分析 工具 可以轻松索引事件。
9.提供同一个单个环境
服务器现在已虚拟化,这意味着它们可以从脚本实例化。这确保了每个环境 - 测试,QA,试验和生产都具有相同的设置。
10.发布由开发团队自己执行
当代码通过单元,集成和系统测试时,开发人员自己可以选择发布它。该过程本身非常简单,因为我们使用基于Web的部署平台。所有这一切归结为按名称选择应用程序,正确的版本号并单击按钮。
这个过程不会在一夜之间发生,甚至不会在几周内发生。实际上,是在我们意识到哪些有效,哪些无效之前,经历了几次迭代以后。
两周前,当我为营销团队发布修复程序时,从疯狂的电子邮件到生产部署的整个过程耗时1小时37分钟。这包括完成每个测试阶段,更新文档,部署和测试QA和试验环境,最后最终耗费时间 - 在将部署版本部署到生产之前等待30分钟的登录会话耗尽。
随着我们迈向API和 开放式银行业务 概念,我们的DevOps战略将进一步发展。不可避免的云计算也将带来自身的挑战和回报。但是,过去几年所做的改变将使我们能够灵活地适应这些挑战。
以上所述就是小编给大家介绍的《SpareBank 1网络银行实现DevOps经验分享 - Somaiah》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 挖洞经验 | 篡改密码重置的加密参数实现账号劫持
- 挖洞经验 | 用HTTP请求重写实现JSON CSRF
- 挖洞经验 | 绕过Facebook CSRF防护机制实现账户劫持
- 利用Cobra实现自动化代码审计的经验分享
- 挖洞经验 | 利用XML和ZIP格式解析漏洞实现RCE
- 挖洞经验 | 用BurpSuite实现越权漏洞(IDOR)的自动发现识别
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。