面临的问题：各个开发工具之间相对独立，没有统一工作流程，导致交付周期长、学习成本高
转型结果：建立了 DevOps 型流水线 个开发工具集成到统一平台，将版本发布周期从 18 个月缩短到了 1 个月。
但见新人笑，哪闻旧人哭，杜甫的诗句很好的诠释了现在 IT 和互联网行业对待技术的态度，区块链、AI、大数据、AR/VR 等新技术层出不穷，任何一个人都在追逐 The Next Thing。在这个被摩尔定律决定的行业，平均每 18 个月就能让计算能力翻倍，让技术井喷。但是过快的发展速度某些特定的程度上也给新的技术带了不稳定性，就像 Gerald Weinberg 说的那样：
在这个即使 2，3 年前的技术也会被认为已经没希望的时代，仍然有很多 50，60 年前的技术活跃在前沿行业中。就像七八十年代科幻电影中的那样，笨重的主机、绿色的屏幕、靠软盘驱动，这些在那个年代帮助人类登上月球的科技被统称为 “Legacy System”。根据 Andreas Hein 的研究，这类 Legacy System 至今仍然在 NASA 被普遍的使用着。
这次带来的案例就是 Legacy System 的缔造者，IBM 的大型机研发部门，作为地球上资历最老的开发团队之一是如何拥抱新的研发管理方式，进行 DevOps 转型的。
当 Radcliffe 和她的团队开始准备向 DevOps 转型的时候，发现主体问题在于现阶段的整个发布周期太长，整套 Z/os 的开发工具太多并且都相互独立，但是整体研发团队的发布周期大概在 12~18 个月左右，整套开发工具中包含了 17 个独立的开发工具。这次转型就希望能将这些独立的开发工具整合到一条固定发布的流水线上，来实现以下目标：
Radcliffe 表示如果能打造一条将这些相对独立的开发工具整合到一起的 DevOps 流水线，能更好地释放团队潜力。将发布周期降到一个月以内，不仅仅能提高研发团队的效率，同时也能为使用大型机的用户带来更多的价值。
转型的目标是要整合所有的开发工具到一条流水线 个开发工具都太过于分散，将其全部统一起来要消耗大量时间。为了能搭建一个通用的 IDE 和环境，Radcliffe 和她的团队采取了一个大胆的举措暂停整个研发进度。
“除了客户出的紧急状况以外，整个团队把全部的精力都放在了这条流水线的搭建上。
因为从最开始就决定要循序渐进，所以整个团队从 IBM 大型机研发中最基本的 Z/os Explorer 和 CICS (IBM 公司的主机交易服务器、整合平台）工具开始着手，然后再按顺序加上其他开发工具。这样所有大型机相关，并以 Eclipse IDE 为基础的开发工具就可以很快地部署到这条流水线上来。
在做这段开发的过程中，值得提及的是这不单单是统一以 Eclipse IDE 为基础的开发工具，更关键的是为了达成这个目标而付出的后端的努力；这不仅仅是 Java 语言的开发，而是 IBM 大型机开发中所使用的传统 PLX 开发模式。这是基于汇编语言的 DevOps 流水线实践，之后将没有独立的开发工具，所有的开发工具都集成到了一个工具链中。现在整个团队只有一个 SEM，不管团队是在为内部系统还是为客户进行开发，所有的代码都在一个仓库里，任何一个人都能清晰的了解其他人的项目和工作进度。
Radcliffe 和她的团队花了 4 个月进行 DevOps 转型，从中她总结了 3 点意见，供其他有兴趣进行转型的企业参考。
必须给予开发团队足够的时间。研发负责人如果想采取 DevOps 的转型就必须花时间给团队做足够的讲解和训练，确保任何一个人都明白他们需要做什么和为何需要这么做，同时要做好前期工作效率下降的准备，尤其是对一些仍然使用传统研发方式的团队来说更是如此。就像我们的 CICS 项目团队，花了一段时间才从老式的开发工具迁移到以 Eclipse 为内核的开发工具。所以在这样的一个过程中需要给予团队足够的时间去学习适应，毕竟罗马不是一天建成的。
保证跨部门沟通渠道的通畅。个人会使用各类 Slack 的频道来进行跨部门沟通，让你们可以实时了解各个项目的进度，可以互相请教和分享关键信息。
管理层必须给予必要的支持。想象一下当整个开发团队在接下来的四个月里都不会进行新功能的交付，会给销售或市场部门带来怎样的波澜。作为管理层，必须要能认识到 DevOps 转型的必要性，相信转型能激发研发团队的潜力，为公司能够带来更高效的交付和更大的价值，这样才可以给你的开发团队足够的支持。
这个案例向我们展示了，即使是像 IBM 的大型机研发团队这样的 Legacy System 项目，只要有足够的支持和决心也能够直接进行 DevOps 转型，为公司能够带来更多的价值。