云时代的研发环境：实施路径

作者：熊节

前文讲到，在云计算的时代大背景下，我们推荐采用研发技术栈管理平台来集中管理组织中的技术栈，允许基于一个技术栈创建开发测试 PaaS 和生产 PaaS 两个 PaaS 服务，从而支撑开发、测试、生产三种运行时环境。通过三种运行时环境的区分，技术栈管理平台实质上设置了一条标准的精益软件生产流水线，为软件研发生命周期中的三个核心工种——开发、测试、运维，布置了标准的“工位”。在实施技术栈管理平台时，从这三个核心工种之中的任何一个切入，都可以优先建设该工种对应的工位，从而拉动整条云化生产流水线的实施。

从开发切入，打造规范的软件开发底座

在数字化的大背景下，众多IT组织都面临技术能力短缺的境况。尤其是传统企业的IT部门，需要用有限的研发专业技能交付越来越多、变化越来越频繁的IT系统，还需要管理外包合作方的团队，对于开发底座规范化的要求日益显著。这些开发团队常见的一些挑战包括：

• 技术实践能力有限，不能保证每个项目采用业界最佳的框架与工具组合。
• 开发流程不规范，代码质量关注不够，技术债累积严重。
• 外包团队管理乏力，对外包团队的开发实践缺乏约束。

实施技术栈管理平台以后，整个组织可以识别并聚焦几种具有普遍代表性的软件形态（例如“ Java 微服务”、“ Java Web 应用”、“安卓移动应用”等），集中技术骨干力量，搭建项目基础架构，以技术栈的形式固化下来。开发团队要启动一个项目时，只需要从技术栈管理的 PaaS 平台上选择自己需要的技术栈，就可以立即生成自己的构建运行时，其中包括代码仓库、应用基础框架、依赖软件、自动化构建工具等。基于这个构建运行时，开发团队可以基于已经搭好的脚手架立即开始编写代码，并在 PaaS 云上进行基本的验证，然后提交到团队代码仓库。团队的技术领导者不需要考虑开发环境应该如何配置，开发人员也不需要在自己的电脑上做任何环境准备工作，从而极大地降低了项目启动的技术门槛。

作为对开发工位的规范要求，技术栈中会规定“提交门”的质量标准，达不到质量标准的代码将无法提交到团队代码库中。这个实践与持续集成一样，都是源自丰田生产方式的“安灯”实践：如果出现质量隐患，应该立即停线修复，而不是让带着质量隐患的生产线继续运转。在一般的开发团队中，提交门的质量标准至少包括（1）代码能通过编译；（2）代码能通过静态质量检查。通过引入代码复杂度、代码规范性检查等基本质量标准，能促使开发团队关注代码质量，避免基本的技术债不断累积。水平较高的团队会在提交门中包含单元测试，单元测试不通过、或单元测试覆盖率达不到标准的代码将无法提交。

如果需要引入外包团队来协助开发，外包团队可以直接从技术栈管理 PaaS 服务商获得自己的构建运行时，绝大部分的开发规范可以用提交门验证的形式来承载，从而将组织的质量要求固化到开发环境中，降低规范化管理外包团队的难度和成本。

从测试切入，建立云测试平台

在数字化、互联网化的IT大背景下，软件系统上线的周期不断缩短，两周一迭代已经成为众多团队的标准配置，一些创新型业务已经要求将上线周期缩短到一周、几天、甚至一天几次。不断缩短的上线周期，使很多 IT 组织在测试方面的问题暴露出来：

• 测试自动化程度低，手工回归测试跟不上频繁上线的节奏。
• 测试环境争用，环境管理工作量大。
• 性能、安全等非功能性需求的测试投入不足，到项目晚期才开始测试。

如果这些问题是一个组织当前最大的痛点，技术栈管理平台的实施也可以从测试工位开始入手，为整个组织打下坚实的质量保障基础。测试和开发的技术骨干可以一同选择适宜的自动化测试工具，将其连接配置好，准备好自动化测试的脚手架，打包到技术栈的验证运行时中。测试人员只需按照业务需求编写自动化测试例，并放在技术栈中规定的“验证门”环节自动执行。当系统最重要的功能都能被自动化测试覆盖，测试人员就能从繁重的手工回归测试中解脱。

自动化测试需要可靠且可复制的测试环境来执行，这正是云计算的优势所在。在技术栈管理 PaaS 中定义了测试运行时环境后，每当测试人员或自动化的验证门要执行自动化测试例时，就会从云中取出一个测试运行时，其中除了被测系统的依赖软件外，还包含了配置好的各种测试工具。被测系统会被加载到测试运行时环境中，执行自动化测试例，收集测试报告，然后测试运行时环境就会被销毁回收。整个过程中不需要测试人员手工管理测试环境，也不需要与其他测试或开发人员共用一套环境。

一旦测试人员不用“人肉回归”大部分软件功能，他们就可以把更多的精力投入非功能性测试。性能测试、安全性测试等非功能性测试所需的工具集同样可以被内建在技术栈中，方便测试人员日常工作。同时，测试人员还可以把非功能性测试编写成自动化的测试例，将其加入验证门的测试集，从而使非功能性需求也持续得到保障，以免在项目晚期才发现重大性能或安全问题。

从运维切入，构建高响应运维能力

同样，数字化、互联网化的大背景也对运维团队提出了新的挑战。从业务客户的角度，他们不仅希望自己的需求能尽快上线被用户使用，而且还希望及时获得来自用户的反馈，帮助他们做出调整。在一些领先的企业，运维更是能支持业务客户针对真实用户进行快速的受控实验，从而验证自己的业务假设。在这些新的要求下，很多 IT 组织的运维团队暴露出了能力上的不足：

• 运维自动化程度低，需要大量手工操作，工作量大，可靠性低，容易出错。
• 系统监控不完备，出现故障时不能及时发现和快速排错。
• 生产系统的信息不能快速转换成业务洞见，无法支持频繁的线上受控实验。

技术栈管理平台的实施同样可以从运维工位入手，以打造高效的 DevOps 体系为优先目标。

你说的是哪种 DevOps ？

由于历史原因，如今大家在谈起 “ DevOps ” 这个词时，其中包含的可能是三重相关但不同的含义：

1. 如何借助基础设施即服务、运维自动化等手段，加快代码部署到生产环境的速度。
2. 如何借助日志和监控手段，及时把生产环境的情况反馈到开发团队。
3. 如何借助端到端的埋点、数据采集、分析和可视化，把用户行为反馈到业务。

以运维视角优先切入时，技术栈的建设就自然地偏向运维工具。在支持计算资源弹性分配的 IaaS 层（例如基于 ScaleWorks 的私有云）之上，将自动化配置管理工具（例如 Chef 、 Puppet 、 Ansible ）及其他常用的运维工具打包在应用运行时中，运维人员可以随时从技术栈管理的 PaaS 服务中获得完整且配置好的应用运行时，再从通过了测试验证（可能是手工验证）的发布候选镜像中选择一个版本放入应用运行时，即可快速完成应用的部署上线。生产环境的配置以代码形式记录，可以由技术能力较强的 DevOps 团队专门维护，从而省去了大多数运维人员手动管理运行时环境的工作量与风险。

在应用运行时环境中，可以根据软件系统的特征预先配置好日志工具（例如 ELK 、 Splunk ）和服务指标监控工具（例如 Collectd ），使开发团队无需额外工作就能获得丰富有用的生产环境信息。一些水平更高的团队会在应用运行时环境中设置更智能化的运维功能（例如基于 Hystrix 的服务熔断机制），使运维更具响应力。

应用运行时环境中还可以植入端到端综合语义监控所需的工具设置，从而支持对业务场景埋点和分析，甚至是结合流量路由技术进行受控实验，用数据为业务决策提供支撑。业务有了缩短反馈周期的诉求，运维有了快速响应变化的能力，两端夹击可以倒逼研发环节提升响应力、缩短交付周期，这也是研发组织变革的一个套路。

小结

技术栈管理平台的目标是为现代 IT 组织创造云环境下的精益软件生产流水线。但对于很多组织而言，这条流水线并非一步到位，而是一个分阶段建设的过程。在这条流水线上，开发-测试-运维三个核心工位都可以成为实施技术栈管理的切入点。从组织当前最显著的痛点出发，选择一个工位开始实施云化的技术栈管理平台，并依循瓶颈理论拉动其他工位的逐步改进，这对于众多不以IT能力见长的组织而言，是一条可行的云化、数字化道路。