给大型机插上翅膀， IBM Z/os 研发团队 DevOps 转型实践

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2647 天前的主题，其中的信息可能已经有所发展或是发生改变。

摘要

企业：IBM 大型机 Z/os 研发团队

企业规模：200 名工程师

面临的问题：各个开发工具之间相对独立，没有统一工作流程，导致交付周期长、学习成本高

转型结果：建立了 DevOps 型流水线，通过 4 个月的研发，把所有 17 个开发工具集成到统一平台，将版本发布周期从 18 个月缩短到了 1 个月。

导读

但见新人笑，哪闻旧人哭，杜甫的诗句很好的诠释了现在 IT 和互联网行业对待技术的态度，区块链、AI、大数据、AR/VR 等新技术层出不穷，每个人都在追逐 The Next Thing。在这个被摩尔定律决定的行业，平均每 18 个月就能让计算能力翻倍，让技术井喷。但是过快的发展速度一定程度上也给新的技术带了不稳定性，就像 Gerald Weinberg 说的那样：

If builders built houses the way programmers built programs, the first woodpecker to come along would destroy civilization.

在这个即使 2，3 年前的技术也会被认为已经没希望的时代，仍然有很多 50，60 年前的技术活跃在前沿行业中。就像七八十年代科幻电影中的那样，笨重的主机、绿色的屏幕、靠软盘驱动，这些在那个年代帮助人类登上月球的科技被统称为 “ Legacy System ”。根据 Andreas Hein 的研究，这类 Legacy System 至今仍然在 NASA 被广泛使用着。

这次带来的案例就是 "Legacy System" 的缔造者，IBM 的大型机研发部门，作为地球上资历最老的研发团队之一是如何拥抱新的研发管理方式，进行 DevOps 转型的。

本次案例整理自 IBM 资深大型机工程师 Rosalind Radcliffe 在 2017 DevOps Enterprise Summit 的分享。讲述像 IBM 大型机 Z/os 研发团队这样传统的开发团队也可以向敏捷转型。

Enjoy ！

设立目标

当 Radcliffe 和她的团队开始准备向 DevOps 转型的时候，发现主要问题在于现阶段的整个发布周期太长，整套 Z/os 的开发工具太多并且都相互独立，但是整体研发团队的发布周期大概在 12~18 个月左右，整套开发工具中包含了 17 个独立的开发工具。这次转型就是希望能将这些独立的开发工具整合到一条固定发布的流水线上，来实现以下目标：

为使用这些大型机和大型机开发工具的内部团队和客户带来更多的价值。
降低使用者的学习成本。
让研发团队能更快更高效的进行功能迭代和版本发布。

Radcliffe 表示如果能打造一条将这些相对独立的开发工具整合到一起的 DevOps 流水线，能更好地释放团队潜力。将发布周期降到一个月以内，不仅仅能提高研发团队的效率，同时也能为使用大型机的客户带来更多的价值。

转型过程

转型的目标是要整合所有的开发工具到一条流水线上，但是现有的 17 个开发工具都太过于分散，将其全部统一起来需要花费大量时间。为了能搭建一个通用的 IDE 和环境，Radcliffe 和她的团队采取了一个大胆的举措暂停整个研发进度。

“除了客户出的紧急情况以外，整个团队把全部的精力都放在了这条流水线的搭建上。"

因为从最开始就决定要循序渐进，所以整个团队从 IBM 大型机研发中最基本的 Z/os Explorer 和 CICS (IBM 公司的主机交易服务器、整合平台）工具开始着手，然后再按顺序加上其他开发工具。这样所有大型机相关，并以 Eclipse IDE 为基础的开发工具就可以很快地部署到这条流水线上来。

在做这段开发的过程中，值得提及的是这不仅仅是统一以 Eclipse IDE 为基础的开发工具，更关键的是为了达成这个目标而付出的后端的努力；这不仅仅是 Java 语言的开发，而是 IBM 大型机开发中所使用的传统 PLX 开发模式。这是基于汇编语言的 DevOps 流水线实践，之后将没有独立的开发工具，所有的开发工具都集成到了一个工具链中。现在整个团队只有一个 SEM，不管团队是在为内部系统还是为客户进行开发，所有的代码都在一个仓库里，每个人都能清晰的了解其他人的项目和工作进度。

Radcliffe 和她的团队总共花了 4 个月的时间完成整个转型。

转型结果

为了将所有开发工具整合，17 个产品总共进行了 94 次版本迭代。
Bug fixes 和小型功能的发布周期缩短到了一个月内。
统一了代码仓库，所有的开发工具都集中在同一环境中。
同时搭建持续部署，每晚自动对部署的功能进行测试，确保高效准确的交付。

反思

Radcliffe 和她的团队花了 4 个月进行 DevOps 转型，从中她总结了 3 点意见，供其他有兴趣进行转型的企业参考。

必须给予研发团队足够的时间。研发负责人如果想采取 DevOps 的转型就必须花时间给团队做足够的讲解和训练，确保每个人都知道他们需要做什么和为什么要这么做，同时要做好前期工作效率下降的准备，尤其是对一些仍然使用传统研发方式的团队来说更是如此。就像我们的 CICS 项目团队，花了一段时间才从老式的开发工具迁移到以 Eclipse 为内核的开发工具。所以在这个过程中需要给予团队足够的时间去学习适应，毕竟罗马不是一天建成的。
保证跨部门沟通渠道的通畅。我们使用各类 Slack 的频道来进行跨部门沟通，让大家可以实时了解各个项目的进度，可以互相请教和分享关键信息。
管理层必须给予必要的支持。想象一下当整个研发团队在接下来的四个月里都不会进行新功能的交付，会给销售或市场部门带来怎样的波澜。作为管理层，必须要能认识到 DevOps 转型的必要性，相信转型能激发研发团队的潜力，为企业带来更高效的交付和更大的价值，这样才能给你的研发团队足够的支持。