许多企业都开始追求通过平台提升开发效率，但送分题如何做成了送命题？本文通过对同一功能、不同开发实现成本的真实投入对比，剖析获得平台效率的关键点，帮助企业更好地权衡平台决策。
近期在实现 X-Developer 与自动化工具的集成上，对平台达成20倍提效，有了量化对比：
- 基于传统的持续集成工具与插件开发模式，以 Jenkins 为例，累计花费 14 个工作日，112 个工时。
- 基于 GitHub Actions 自动化平台，大约花费 5~6 个工时，实际上是 1 个工作日完成了两个 Cloud CI 平台的集成，摊到 GitHub Actions 上差不多 5~6 小时，有一些不必要的返工，细节下文详述。
明明白白的结论：5.5 : 112≈20 倍效率。
以下就是具体的工作量分解，让我们充分洞察出效率提升的原因。
基于框架开发：效率瓶颈在领域模型熟悉程度
由于我们对 Jenkins 的整体架构比较熟悉，包括其内部存储体系、节点通信原理、构建流程以及插件管理机制，所以要开发一个 Jenkins 插件，需要做的只是熟悉一下最新版本的规范，快速搭建起开发框架往里面填充实现就可以了。对不熟悉 Jenkins 架构的开发者来说，理解基本概念，最少可能要花上 1 个月时间。
#1 浪费：环境和工具
在有基础的情况下，第一个工作日还是完全浪费在了：环境和工具。作为一款主要定位为编辑器的工具，搭建 VSCode Java 开发环境确实麻烦，难怪微软还专门出了个 Java 工具包。加上 Jenkins 有大量外部库，在 VSCode 中显示天量红色波浪线，极度影响判断，果断弃用 VSCode 切换到 Intellij IDEA，问题解决。
IDE 问题解决了，但无法根据 Jenkins 官方说明创建插件工程。花了些时间分析，结果是万恶的网络速度问题导致本地加载插件清单文件超时。通过本地存档一份 archetype 文件，解决，经过漫长的(超过 4 个小时)依赖包下载，开始创建第一个插件工程。
#2 浪费：框架编程模型
第一个知识的挑战就来了：五类插件工程，建哪一类？不熟悉插件内部的编程模型，就只能从 hello world 这个类型着手了，虽然它没有任何实质性的产出，但你连 hello world 都不会，也就不可能有任何进展了。
Jenkins 帮助插件开发者解决了一些通用的编程功能场景：
- 表单配置项的存取，不需要考虑背后的细节；
- 构建上下文读取和构建日志输出，能够立即获取到 Git 仓库信息并将分析工具的输出对接到构建器；
- 多语言支持，中英文切换不需要考虑如何实现；
- 单元测试、集成测试，Jenkins 运行环境都能够通过 maven 的测试构建命令自动创建运行销毁，极大地提升了测试效率。
总结，Jenkins 插件开发框架，在你完成开发编码后，仅通过一条命令行就可以完成所有编译、构建、打包以及人工测试的工作，所有环节通过后，就生成了待部署的插件包，这个过程视功能数量而定，X-Developer Client Plugin 差不多跑 6 分钟。
作为集成构建领域的主流开源框架，Jenkins 提供的功能已经足够强大了，企业级应用框架如果能做到这一步，持续自动化地完成从代码构建、测试、集成、打包，就已经极大地解放了生产力。
#3 浪费：框架运行时
跑通 hello world ，开发者可以信心十足地开始正式的功能开发了，这时已经过了 2 个工作日。
第 3 个工作日，实现主要功能，包括 Git 仓库日志生成、HTTP 传输，这些功能在以前 Python 命令行集成工具中都已经开发过，所以只是换了 Java 语言实现，先通过 JUnit 测试通过，分析服务也跑通。但采用 Jenkins 单元测试时，找不到 Git 命令：框架内部无法获取 Java 应用程序的 Runtime ，所以基于 Java Runtime 调用的命令行无法运行。
接下来就不得不深入 Jenkins Core 的细节了，你必须了解它对所有命令工具的调用机制，才能正确地实现插件功能。
在并不知道它的工作原理，也没有任何参考文档的情况下，由于 Jenkins 项目本身也已经是一个庞大的遗留系统，相似的实现很多，我们不得不参考了 Jenkins 内外部多种实现的源码，比如花了很多时间尝试 hudson.tasks.shell ，最终前后差不多花了 7 个工作日、尝试了 3 种实现，跑通了命令行日志生成。一些不得不多次尝试的细节还包括，作为分析而非构建步骤，到底该继承 hudson.tasks 中的 Builder、Publisher、Notifier 还是 Recoder ？最后我们把经过深思熟虑编写的代码提交到社区进行 Code Review，得到了以下反馈：
Is appKey kind of like a password or API token? If so, it needs to be stored in a hudson.util.Secret instead of a normal string. (master/src/main/java/org/jenkinsci/plugins/xclient/Configuration.java#L30)
缺了资深开发，普通的开发者真的很难正确地执行框架开发，它永远都需要有守护者。
#4 浪费：遗留系统集成
把 Git 跑起来后才面对真正的问题：复杂的集成测试。
插件提供的用于自动化测试的 Jenkins 仅是一个最小化的 war 包，没有安装 Git ，无法测试包含 Git 命令行的插件。通过插件依赖引用，遇到了 Apache HTTP Client 5 以及 Java 1.8 版本与 Git 插件老旧依赖的冲突，屏蔽之后依然不能解决问题：Jenkins 插件构建过程中会强制检查依赖版本冲突。只能改为手工安装 Jenkins 再手工测试，效率一下就降下来了。
最后这一简单功能的测试，仅仅调整了一些表单、日志呈现上的细节，就花费了3~4天。其中还包括解决中文属性文件的乱码问题：框架竟然没有考虑到这一基本的功能。
从这个开发案例可以理解框架的作用：
- 通过模型抽象，为一个领域提供了通用解决方案。
- 简化了编程语言层面的工作，但不彻底，毕竟它的主要任务还是提供领域级的解决方案。
- 抽象模型，简化编码复杂度的同时也引入了理解的复杂度。
因为这个插件要提供的功能非常简单：调用一行命令 + HTTP 传输，不集成任何三方自动化工具的情况下，最多也只需要 1 天就可以开发完成，而框架把这个工作量扩大了 14 倍，仅仅是帮助最终用户提升了安装配置体验，两者花的时间呢，其实都差不多。
所以仅仅提供框架，对熟练的开发者有一定的效率提升，不需要从零开始构建解决方案；但有更高的学习曲线，并且不一定具有清晰可见的最终用户感知价值。
基于平台：效率瓶颈在生态意识
说到 GitHub Actions ，其实去年就有同行向我们推荐了，并且建议我们把产品发布到 GitHub Marketplace 。
当时研究了一下，认为 GitHub 平台的自动化功能还相当弱，用户数量也不多，不值得投入，一个月前咱们的重点还在于集成类似 TravisCI 这样的持续集成云平台。
但随着越来越多的用户反馈咱们的产品使用复杂、曲线陡峭，我们重新定位了产品的最小依赖环境。
简单地说，X-Developer 提供近实时的、基于 Git 仓库事实数据的研发效能洞察。Git 仓库肯定必不可少，实时分析依赖于仓库监听功能，而仓库监听对 CI 来说是基础功能，所以，依赖于 CI 工具环境是最佳选择。
目前研发效能度量领域才刚起步，无论是 Git 仓库还是 CI/DevOps 工具，在领域模型设计上都没有很好地预留生命周期节点和接口。
咱们开始考虑基于 Git 仓库自动化来直接实现分析功能，结果是：1 天就实现了。充分体验到了平台效率。
进入 GitHub Actions 到跑通，主要经历了这几个步骤。
1. 进入一个待集成的测试代码库，点击菜单按钮“Actions”，进入 Action 创建界面；
2. 可以看到图形化的各类 Actions 菜单，选择 Suggested 的 Simple workflow 来配置，集成之前开发的 Python 命令行工具。
3. 点击 Start commit，此文件将被提交并触发内部定义的动作，即时看到结果。
完整操作下来 5 分钟不到，几个小时花费在了配置读取环境变量，以及配错了 APPID APPKEY后，由于在平台上无法调试，Secrets 也无法打印，花了两个小时来找原因，一直以为是读取不到 GitHub Secrets 最后发现了填写的是本地 localhost 帐号~这也许是平台化开发的一个天然坑了。
当然 Python 路线的正确选择也是快速集成成功的前提。作为一款非常适合云平台开发的语言，Python 与各类操作系统、云平台天然兼容，不需要考虑 Java 那么复杂的环境和依赖问题。我们只开发了一款 Python 的模块，就全面集成所有的平台了，真正实现了：一次编写，多次复用。
GitHub Actions，从听说到应用，经过了半年，犯下低级错误模式下依然 5~6 个小时集成成功，20 倍效率成功 GET ^_^ 阻碍我们使用这一效率倍增操作简单的神器，其实是我们的思维惯性。
下面我们就来详解一下它的提效之道。
智能化平台：自动化 + 可移植的操作指令集
GitHub Actions 和 IFTTT 类似，或者说，它基本上就是借鉴了 IFTTT 的设计概念。
IFTTT 是提供多个手机 Apps 自动化的解决方案平台，它通过内置的调用 Apps API 的 Trigger + Action 组成 Recipe，实现 App A 对 App B 的自动触发与数据传送。比如说，某个 Recipe 是连接摄像头与微信，我们利用这个 Recipe 就可以实现拍照后自动发布朋友圈。Recipes 可以在 IFTTT 上开放分享，我们就可以很好地复用其它人的创作结果，极大地简化自己去一个个设置这些连接操作。
GitHub Actions 是 Git Hook Trigger 与 Pipeline as Code 的集合，与 Cloud CI 比如 TravisCI 这类平台对比，有所异同：
相同的本质之处，都是基于云端的脚本化构建。Cloud CI 平台由于已经有数年发展历史，在功能上更全面、生态上更丰富，比如说语义化发布，通过 semantic-release 等工具在 TravisCI 上可以直接进行授权完成公有仓库发布，而在 GitHub 中还需要自行手动配置。还有环境变量管理等一系列云平台的管理细节，GitHub 的基础是代码仓库而非云基础设施，在使用上还不如 Cloud CI 便利 - 基于 TravisCI 实现 X-Developer 集成实际上只花了 2 个小时。
GitHub Actions 提供的大杀器就是类 IFTTT 这样的可分享和市场化应用。创建 Actions 代码后，只需要添加一个 action.yml 就可被 GitHub 感知为可发布的 Actions 程序，一键就可以发布到 Marketplace ，无须审核。你也可以在仓库的 Release 栏目通过勾选“Publish this Action to the GitHub Marketplace”直接推送。
发布成功后，其它用户可在 Marketplace 中搜索、查看 Action，还可以在 Action 的代码仓库上直接看到使用提示。
Marketplace 展示效果
代码仓库展示效果
平台的三点启示
Winner takes ALL - 赢家通吃是平台的基本特征。比如说 GitHub 上已经聚焦了超过 4000 万的用户、300 万个组织以及 4400 万个仓库。由于协同效应，很难迁移到别的 Git 平台，所以 GitLab 及其它 Git 仓库产品，只能从其它细分市场，比如开源、企业级、私有部署上寻找突破点。
Market over products - 数字化平台已经超越了此前的狭义技术定义，比如提升组件重用度提升开发效率、作为内外资源共享平台提升开放创新能力等，进入了广义定义：平台即市场，而非一些产品或资源的整合。
Digital Ecosystem -生态、生态、生态。TravisCI 仅仅只能定位为一款自动化工具，就是它不具备连接多个利益方的生态。挑战一个工具是很容易的，但挑战一个生态是很难的，另一个例子是 Jira ，你可以很快重新做一套比 Jira 更好用的项目管理工具，但你要复制 Jira 从代理商、插件到社区、Vendors 支持的整套生态，却很难，只要有利益相关者依赖于 Jira 生态环境来生存，他们就会促进这个生态系统的不断创新与进步。而 GitHub/Jira 这些平台理念，还未被国内厂商充分地理解和运用：尚在构建类似于 Jenkins 框架的领域平台解决方案框架而非真正的平台，对最终用户和业务获得的效率影响，其实微乎其微。
最后，介绍一下新上架的 X-Developer Analysis Action 吧，只需一键一分钟，就为你的 GitHub 仓库集成了研发效率度量分析功能，天下武功，唯快不破！
https://github.com/marketplace/actions/x-developer-analysis-action
关于场量科技：作为一家创新型公司，我们开发了全球第一款事实数据型研发效能度量分析平台。使用我们的平台与开源工具，无需购买、设置或管理任何基础设施，您只需登录即可开始开展研发团队效能改进工作。目前，X-Developer提供了最便捷、完整的研发效能度量解决方案，让您能够以开发者为中心展开改进活动，使您的团队能够围绕目标协同工作，及时同步项目进展，从而将他们从繁重的任务状态维护、项目报告工作中解放出来，集中精力完成研发工作，更好地编写代码，提高业务获得的价值。
扫一扫
788
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
