作者：熊节
前文介绍了云计算大背景对研发环境的影响。我们已经指出，现代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 等技术，将技术栈的结构以源代码的形式描述。在“基础设施作为源代码”的阶段我们已经知道，以源代码形式管理环境会带来很多好处，例如更高的自动化程度、允许版本控制等。把技术栈作为源代码以后，会带来几个重要的收益：
- 技术栈可以很容易地复用，因此可以把搭建技术栈的工作收拢到较少数技术领导者手中，研发团队则只需在技术栈基础上开发业务功能，降低了研发团队的技能门槛。
- 最佳实践可以被内嵌到技术栈中，并通过持续集成的形式对研发团队形成约束，从而使研发改进举措更容易推行。
- 缩短研发实践的实验和创新周期，可以对多个研发团队开展受控对比实验，团队中自发产生的优秀实践可以被快速抽取并固化到技术栈中。
技术栈管理平台作为组织级的研发管理载体，承载的是组织对研发团队的引领和治理形式。在这个平台上，技术领导者会创建并维护技术栈，项目团队则可以根据自己的需要选择适合的技术栈，跳过大部分迭代0的技术准备工作，直接进入功能开发，并在整个产品生命周期中享受云化开发环境带来的收益。
两个 PaaS
基于已经定义好的技术栈，当项目团队开始研发工作时，技术栈管理平台可以为他们创建两个 PaaS 服务：一个是研发过程中使用的开发测试 PaaS ，另一个是真实上线用的生产 PaaS 。两个 PaaS 的协作关系如下：
- 开发人员从开发测试 PaaS 中获得一个开发环境，在这个环境中编写代码；
- 新编写的代码被提交到代码库中，后台的服务自动运行“提交门”测试，测试通过后，把代码构建成可运行应用；
- 后台服务针对可运行应用自动运行“验证门”测试，测试通过后，这个版本的可运行应用即被标记为可发布应用，并被存入构建产物仓库；
- 测试人员针对通过了“验证门”测试的可发布应用进行必要的手工验证；
- 生产环境与开发/测试环境基于同一个技术栈（运行时环境上有具体的差别），开发测试 PaaS 中构建出的可运行应用可以直接部署到生产环境；
- 随不同组织的发布流程不同，构建产物仓库中的可发布应用可能直接（自动或手动）发布到生产环境，也可能被同步到生产 PaaS 的产品仓库，以后再手动发布到生产环境。
可以注意到，这个流程、尤其是在开发测试PaaS中发生的流程，与 Dave Farley 在《一键发布》文中介绍的持续集成流水线非常相似。我们相信：持续集成对于现代软件开发是如此重要，以至于它不应该以独立的工具形式存在（因为这样人们就有可能不用或者误用）。持续集成应该被内建在软件开发的工具和过程中，使它不被开发者注意、同时又不能被绕开——正如 Spring 内建了面向接口编程、IntelliJ IDEA 内建了编译和代码格式检查。
三个运行时环境
前面介绍的流水线已经暗示，在整个软件交付周期中，存在三个不同的运行时环境。这三个运行时环境都有同样的基础，例如操作系统、依赖软件等。同时它们也有一些重要的差异：
- 构建运行时：包含开发工具、构建工具和（可能是部分）测试工具，这是开发人员编写代码的主要环境——需要注意，“编写代码”在敏捷软件开发的上下文中意味着“编写代码并频繁进行提交门测试”，这是为什么这个运行时环境中必须包含（至少部分）测试工具。
- 验证运行时：包含全部测试工具及其他质量保障工具，这是对软件质量进行全面验证的主要环境。
- 应用运行时：包含运维工具，这是软件真正运行的环境。这个运行时可能被应用于生产环境，也可能仅用在组织内部（例如 UAT 测试环境、培训环境、demo 环境等）。这个运行时中的依赖软件（尤其是数据库）也有可能被替换为环境之外独立运行的软件。
尽管为了支持不同环节的工作要求而有这些差异的存在，底线是：构建运行时构建出来的可运行应用，可以在验证运行时中接受完整的验证，也可以被部署到应用运行时正常运行。这与持续交付中“制成件流过整个流水线”（而非在各个构建步骤中分别生成制成件）的理念是一致的。
制成件的形式
在前文中我们已经提到：软件包是一种对云环境不友好的交付形式，理想的研发交付物应该是容器镜像（很可能是一组彼此连接的容器镜像），可以在云上直接运行。Docker 等容器技术使我们可以把所有软件（不论背后使用什么编程语言、实现什么功能）都抽象为“ IP 地址 端口”的服务；再加上例如 Docker Swarm 或 Kubernetes 之类集群工具的支持，更可以把服务进一步简化为一个端口。于是，技术栈管理的基础设施可以得到更大程度的复用：不同的技术栈（不管编程平台是 Java、NodeJS 还是 Python ）构建出的应用都是一个（或一组）Docker 镜像，从而将“产物的形态”与“生产流程的结构”解耦。
小结
针对前文提出的云计算大背景下对软件研发提出的挑战，本文提议了一种解决方案：技术栈管理平台。通过实施技术栈管理平台，为研发团队提供开发测试 PaaS 和生产 PaaS 两个 PaaS 服务、构建/验证/应用三个运行时环境，研发组织能够将技术栈的搭建和管理与业务系统的研发解耦，从而降低研发团队技能门槛、快速有效地推广研发最佳实践、使研发过程中的技术与流程实验和创新成为可能。
