您好,欢迎访问专业IT管理知识分享平台

上传文档

当前位置:首页 > 文章列表 > 在甲骨文主导 DevOps 的变革是一种什么体验?

「流程管理」在甲骨文主导 DevOps 的变革是一种什么体验?

前言

刚结束的深圳 GOPS 2017 全球运大会上,来自 JFrog 的全球研 Jagan Subramanian 表了演

Jagan 之前在甲骨文供16年,担任高发总监。由于之前甲骨文收购了很多公司,这些新的团队使用不同的语言开发,不同的仓库存储自研件,并且各种维护不同的上线流程,导致公司内部的软件交付流程非常混乱。同时随着软件微服务架构的落地,团队产生的包越来越多,团队之间很难协作。

为了解决这些痛点,在2013年,Jagan 开始负责开发甲骨文内部持续交付的 PaaS 平台,名叫 Carson,目的是为公司内部所有的开发团队提供统一的,自助式的持续交付平台。

在底层 DevOps 工具的选择上,为了满足团队开发语言多样化,需要统一,自助式软件交付流水线的管理,跨团队之间协同构建,发布等需求, Jagan 比较了很很多工具,最终选择了 Artifactory Jenkins/Hudson 作为底层的工具,在上层开发了 Carson,实现了统一,自助式持续交付的平台。目前这个平台已经为甲骨文内部几万个开发者使用,为公司管理了1亿多个软件包。

Jagan 成功主了甲骨文中件,数据线 DevOps 变革。如果您也想成为公司内部推DevOps的领袖,就来参考下 Jagan 经验

1、甲骨文的痛点

  1. Stack Build 构建耗长。

    Stack Build 是指的 A 构建 BB 构建 C致在重复 Stack Build ,需要花大量的时间

  2. 同一个依包有多个版本被引用。

    例:团队 A 了一个共用包,比如是解析 MQ 消息通用服 common.jar V1.0B C 团队都引用了,一个月后 A 团队了,B 引用了common.jar V1.1,但 C 没有升,在集成 ABC 的服务时个通用服被引入了common.jar 的两个版本。

  3. 用内部接口。

    例:当团队A,急需团队 B的数据, A 然知道不应该直接 B 的内部方法,但 A是会要求 B 提供一个内部方法,等 B 好了外部接口,A 再来改代码调用外部接口。但实际情况是 A 完成了功能交付了代之后,再也不会做重构。这样致了 A B 直接的耦合。

  4. 关系混乱。

    当某个中件需要重构,他并不知道公司内部哪些品会被影响到,因每个人看起来都会被影响。

  5. 者的境通常和生产环境不一致。

    例:开者在本地测试问题,放到客户环境或者线境就出问题

  6. 缺乏透明度,可化。

    团队中每个人都看不到当前的流程,没法估当前流程有什么可以改的地方。例如缺乏每次构建的时间测试覆盖率,测试率,上线成功率,布周期等指统计致。

  7. 传统的工具以适配新的技

    例如 C/C++ 的依管理就是个很大的痛点,由于 C/C++ 编译不能跨平台,它依编译工具 cmake 或者 gcc,也依与芯片架构,所有缺少一个似于 Maven 的依管理工具来管理所有的包。

  8. 实现云化。

    在申请计算,存,网络资,依于硬件,没有实现化,按需建,消费资源。

2、Jagan在甲骨文推DevOps的方法


  1. 定位问题

    公司内部 DevOps 袖,你应该让测试,运 Leader 坐在一起,从公司的角度来思考面问题,确保三个团队朝相同的方向努力。

  2. 实验方案。

    三个团队 Leader 一起讨论如何改公司的流程,讨论每个团队需要改什么。在段,要尽量行足多的 POC,找个合适的方案解决公司问题

  3. 实现方案。

    和上一步 POC 的人一起行方案的实现。此你需要解决基础设施的问题,保础设施能支持些方案。

    测试要注意元数据的收集,例如每次构建的时间测试覆盖率,测试率,上线成功率,布周期。些数据将来是行持度量的重要数据来源。

  4. 采用方案。

暂时没有评论,评论一个吧?

您需要登录后才能评论 , 去登录

Powered by DS文库

Copyright © 专业IT管理知识分享平台 All Rights Reserved. 鄂ICP备19005274号-1
×
保存成功