透明思考


Transparent Thoughts


技术栈管理:云时代的研发环境

前文介绍了云计算大背景对研发环境的影响。我们已经指出,现代IT组织应该把研发技术栈以PaaS的形式提供给开发人员,其中的要点是:

  • 将标准的研发环境封装为虚拟化、云化的技术栈,由技术专家管理维护;
  • 核心业务价值与技术支撑解耦,工程师专注于业务系统的开发;
  • 自动化研发流程,降低研发管理成本。

如何实现这样一个研发技术栈管理的平台?我们的观点是,这样一个平台应该集中管理组织中的技术栈,允许基于一个技术栈创建开发测试PaaS和生产PaaS两个PaaS服务,从而支撑开发、测试、生产三种运行时环境

一个平台

在一个典型的敏捷软件开发场景(例如更具体的“用Java开发微服务”的场景)中,开发者需要频繁地用到下列工具:

  • 编程框架,提供基础的结构与功能来支撑业务逻辑代码,例如Spring Boot和Jersey。
  • 版本控制工具,例如git。
  • 依赖软件,例如PostgreSQL数据库。
  • 自动测试工具,包括单元测试工具(TestNG)和功能测试工具(Concordion、Selenium)。
  • 自动构建工具,Maven或Gradle。
  • 持续集成工具,Jenkins或GoCD。

所有这些工具以及它们适当的组合与配置,我们把它称为一个技术栈。我们上面的例子就是“Java微服务开发技术栈”,类似的,一个组织中还可以有“Java Web应用开发技术栈”、“H5前端开发技术栈”、“ReactNative移动应用开发技术栈”等等若干个技术栈。对于一般的IT组织而言,有限的几种技术栈就可以覆盖大部分软件项目的形态。体量大如有数万研发员工的某IT巨头,提出的主要技术栈也只有十余种。

在传统的软件开发团队中,技术栈的组合与配置是由团队的技术领导者负责的。在云计算的大背景下,将基础设施作为源代码的思想再往前推一步,我们就会很自然地得出技术栈作为源代码的想法:使用Docker和Ansible等技术,将技术栈的结构以源代码的形式描述。在“基础设施作为源代码”的阶段我们已经知道,以源代码形式管理环境会带来很多好处,例如更高的自动化程度、允许版本控制等。把技术栈作为源代码以后,会带来几个重要的收益:

  1. 技术栈可以很容易地复用,因此可以把搭建技术栈的工作收拢到较少数技术领导者手中,研发团队则只需在技术栈基础上开发业务功能,降低了研发团队的技能门槛。
  2. 最佳实践可以被内嵌到技术栈中,并通过持续集成的形式对研发团队形成约束,从而使研发改进举措更容易推行。
  3. 缩短研发实践的实验和创新周期,可以对多个研发团队开展受控对比实验,团队中自发产生的优秀实践可以被快速抽取并固化到技术栈中。

技术栈管理平台作为组织级的研发管理载体,承载的是组织对研发团队的引领和治理形式。在这个平台上,技术领导者会创建并维护技术栈,项目团队则可以根据自己的需要选择适合的技术栈,跳过大部分迭代0的技术准备工作,直接进入功能开发,并在整个产品生命周期中享受云化开发环境带来的收益。

两个PaaS

基于已经定义好的技术栈,当项目团队开始研发工作时,技术栈管理平台可以为他们创建两个PaaS服务:一个是研发过程中使用的开发测试PaaS,另一个是真实上线用的生产PaaS。两个PaaS的协作关系如下:

  • 开发人员从开发测试PaaS中获得一个开发环境,在这个环境中编写代码;
  • 新编写的代码被提交到代码库中,后台的服务自动运行“提交门”测试,测试通过后,把代码构建成可运行应用;
  • 后台服务针对可运行应用自动运行“验证门”测试,测试通过后,这个版本的可运行应用即被标记为可发布应用,并被存入构建产物仓库;
  • 测试人员针对通过了“验证门”测试的可发布应用进行必要的手工验证;
  • 生产环境与开发/测试环境基于同一个技术栈(运行时环境上有具体的差别),开发测试PaaS中构建出的可运行应用可以直接部署到生产环境;
  • 随不同组织的发布流程不同,构建产物仓库中的可发布应用可能直接(自动或手动)发布到生产环境,也可能被同步到生产PaaS的产品仓库,以后再手动发布到生产环境。

可以注意到,这个流程、尤其是在开发测试PaaS中发生的流程,与Dave Farley在《一键发布》文中介绍的持续集成流水线非常相似。我们相信:持续集成对于现代软件开发是如此重要,以至于它不应该以独立的工具形式存在(因为这样人们就有可能不用或者误用)。持续集成应该被内建在软件开发的工具和过程中,使它不被开发者注意、同时又不能被绕开——正如Spring内建了面向接口编程、IntelliJ IDEA内建了编译和代码格式检查。

三个运行时环境

前面介绍的流水线已经暗示,在整个软件交付周期中,存在三个不同的运行时环境。这三个运行时环境都有同样的基础,例如操作系统、依赖软件等。同时它们也有一些重要的差异:

  1. 构建运行时:包含开发工具、构建工具和(可能是部分)测试工具,这是开发人员编写代码的主要环境——需要注意,“编写代码”在敏捷软件开发的上下文中意味着“编写代码并频繁进行提交门测试”,这是为什么这个运行时环境中必须包含(至少部分)测试工具。
  2. 验证运行时:包含全部测试工具及其他质量保障工具,这是对软件质量进行全面验证的主要环境。
  3. 应用运行时:包含运维工具,这是软件真正运行的环境。这个运行时可能被应用于生产环境,也可能仅用在组织内部(例如UAT测试环境、培训环境、demo环境等)。这个运行时中的依赖软件(尤其是数据库)也有可能被替换为环境之外独立运行的软件。

尽管为了支持不同环节的工作要求而有这些差异的存在,底线是:构建运行时构建出来的可运行应用,可以在验证运行时中接受完整的验证,也可以被部署到应用运行时正常运行。这与持续交付中“制成件流过整个流水线”(而非在各个构建步骤中分别生成制成件)的理念是一致的。

制成件的形式

前文中我们已经提到:软件包是一种对云环境不友好的交付形式,理想的研发交付物应该是容器镜像(很可能是一组彼此连接的容器镜像),可以在云上直接运行。Docker等容器技术使我们可以把所有软件(不论背后使用什么编程语言、实现什么功能)都抽象为“IP地址+端口”的服务;再加上例如Docker Swarm或Kubernetes之类集群工具的支持,更可以把服务进一步简化为一个端口。于是,技术栈管理的基础设施可以得到更大程度的复用:不同的技术栈(不管编程平台是Java、NodeJS还是Python)构建出的应用都是一个(或一组)Docker镜像,从而将“产物的形态”与“生产流程的结构”解耦。

小结

针对前文提出的云计算大背景下对软件研发提出的挑战,本文提议了一种解决方案:技术栈管理平台。通过实施技术栈管理平台,为研发团队提供开发测试PaaS和生产PaaS两个PaaS服务、构建/验证/应用三个运行时环境,研发组织能够将技术栈的搭建和管理与业务系统的研发解耦,从而降低研发团队技能门槛、快速有效地推广研发最佳实践、使研发过程中的技术与流程实验和创新成为可能。

(本文作者熊节是ThoughtWorks的总监咨询师)