您好,欢迎访问专业IT管理知识分享平台
当前位置:首页 > 文章列表 > 在甲骨文主导 DevOps 的变革是一种什么体验?
在刚结束的深圳 GOPS 2017 全球运维大会上,来自 JFrog 的全球研发副总裁 Jagan Subramanian 发表了演讲。
Jagan 之前在甲骨文供职了16年,担任高级研发总监。由于之前甲骨文收购了很多公司,这些新的团队使用不同的语言开发,不同的仓库存储自研件,并且各种维护不同的上线流程,导致公司内部的软件交付流程非常混乱。同时随着软件微服务架构的落地,团队产生的包越来越多,团队之间很难协作。
为了解决这些痛点,在2013年,Jagan 开始负责开发甲骨文内部持续交付的 PaaS 平台,名叫 Carson,目的是为公司内部所有的开发团队提供统一的,自助式的持续交付平台。
在底层 DevOps 工具的选择上,为了满足团队开发语言多样化,需要统一,自助式软件交付流水线的管理,跨团队之间协同构建,发布等需求, Jagan 比较了很很多工具,最终选择了 Artifactory 和 Jenkins/Hudson 作为底层的工具,在上层开发了 Carson,实现了统一,自助式持续交付的平台。目前这个平台已经为甲骨文内部几万个开发者使用,为公司管理了1亿多个软件包。
Jagan 成功主导了甲骨文中间件,数据库等产品线的 DevOps 变革。如果您也想成为公司内部推动DevOps的领袖,就来参考下 Jagan 经验!
Stack Build 构建耗时很长。
Stack Build 是指的 A 构建时依赖 B,B 构建时依赖 C,导致在重复 Stack Build 时,需要花费大量的时间。
同一个依赖包有多个版本被引用。
举例:团队 A 开发了一个共用包,比如是解析 MQ 消息通用服务 common.jar V1.0。B 和 C 团队都引用了,一个月后 A 团队升级了,B 引用了common.jar V1.1,但 C 没有升级,在集成 A,B,C 的服务时,这个通用服务被引入了common.jar 的两个版本。
调用内部接口。
举例:当团队A,急需获得团队 B的数据, A 虽然知道不应该直接调用 B 的内部方法,但 A还是会要求 B 提供一个内部方法,等 B 定义好了外部接口,A 再来改代码调用外部接口。但实际情况是 A 完成了功能交付了代码之后,再也不会做重构。这样就导致了 A 和 B 模块直接的紧耦合。
依赖关系混乱。
当某个中间件需要重构,他并不知道公司内部哪些产品会被影响到,因为每个人看起来都会被影响。
开发者的环境通常和生产环境不一致。
举例:开发者在本地测试没问题,放到客户环境或者线上环境就出问题。
缺乏透明度,可视化。
团队中每个人都看不到当前的流程,没法评估当前流程有什么可以改进的地方。例如缺乏每次构建的时间,测试覆盖率,测试通过率,上线成功率,发布周期等指标的统计,导致。
传统的工具难以适配新的技术。
例如 C/C++ 的依赖管理就是个很大的痛点,由于 C/C++ 的编译依赖不能跨平台,它依赖与编译工具 cmake 或者 gcc,也依赖与芯片架构,所有缺少一个类似于 Maven 的依赖管理工具来管理所有的包。
实现云化。
在申请计算,存储,网络资源时,依赖于硬件,没有实现虚拟化,按需创建,消费资源。
定位问题。
作为公司内部 DevOps 的领袖,你应该让开发,测试,运维的 Leader 坐在一起,从公司的角度来思考面临的问题,确保三个团队朝相同的方向努力。
实验方案。
让三个团队的 Leader 一起讨论如何改进公司的流程,讨论每个团队需要改变什么。在这个阶段,要尽量进行足够多的 POC,找个合适的方案解决公司问题。
实现方案。
和上一步 POC 的人一起进行方案的实现。此时你需要解决基础设施的问题,保证基础设施能够支持这些方案。
在测试要注意元数据的收集,例如每次构建的时间,测试覆盖率,测试通过率,上线成功率,发布周期。这些数据将来是执行持续度量的重要数据来源。
采用方案。
您需要登录后才能评论 , 去登录
Powered by DS文库
Copyright © 专业IT管理知识分享平台 All Rights Reserved. 鄂ICP备19005274号-1
暂时没有评论,评论一个吧?