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

作者:熊节

前文介绍了云计算大背景对研发环境的影响。我们已经指出,现代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 服务、构建/验证/应用三个运行时环境,研发组织能够将技术栈的搭建和管理与业务系统的研发解耦,从而降低研发团队技能门槛、快速有效地推广研发最佳实践、使研发过程中的技术与流程实验和创新成为可能。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏技术墨客

multi-tenant solution(多租户方案)说明

今天在研究vertx-Metrics时碰到了一个multi-tenant solution的概念,特此整理记录相关资料。

672
来自专栏DevOps时代的专栏

一篇文章搞清楚 CI, CD AND CD

CI, CD AND CD 当我们在谈论现代的软件编译和发布流程的时候,经常会听到CI 和CD这样的缩写短语。CI很容易理解,就是持续集成。但是CD既可以指代码...

2178
来自专栏美团技术团队

美团点评酒旅前端的技术体系

酒旅前端团队的技术体系 随着科技的发展,终端种类越来越丰富,前端作为连接用户终端与后端服务、提供视觉体验的关键环节,发展迅速。相比十年前,前端的边界和范围变得更...

35111
来自专栏企鹅号快讯

互联网应用架构标准模型

随着互联网的普及,越来越多的企业也开始往互联网化转型,相应的企业也要为此构建配套的互联网应用。软件架构方面,很多企业一味求快,而放弃很多需要坚持的原则,这会带来...

1990
来自专栏性能与架构

持续集成、持续交付、持续部署 的区别与关系

持续集成 尽可能快的把不同开发人员修改的代码集成到一起,通常一天进行多次 需要结合自动化单元测试,每次集成都运行一整套单元测试 目标是尽快发现代码问题 ...

2835
来自专栏张善友的专栏

SQL Server 2012将与Hadoop无缝集成

SQL Server 2012致力提供大规模且低成本的分析数据和数据仓库解决方案,并保证实现规模化和灵活性。在大数据时代Microsoft也做出了一些完善。 结...

1759
来自专栏云计算D1net

如何最小化云API升级造成的中断?

云提供商升级API时,开发者必须升级并重新测试自己的软件,如何为这个过程做好准备并且最小化影响? 云提供商为了扩展和改善服务进行了服务升级,通常需要进行API升...

2643
来自专栏DevOps时代的专栏

高效持续交付的 7 大原则

如果你身处IT领域,并且你不是昨天才出生的,那么你一定理解速度的必要性。自从企业实施了持续集成(CI)和持续交付(CD),开发与交付周期要比过去快了很多。举个例...

932
来自专栏Albert陈凯

Hadoop离线数据分析平台实战——420订单分析Hadoop离线数据分析平台实战——420订单分析

Hadoop离线数据分析平台实战——420订单分析 项目进度 模块名称 完成情况 用户基本信息分析(MR)� 完成 浏览器信息分析(MR) 完...

2906
来自专栏EAWorld

移动开发的跨平台实践及在企业中的应用

目录: 一、移动跨平台已成为必然 二、驱动原生是移动跨平台的最佳选择 三、以工程化的形式解决移动跨平台问题 四、普元在企业移动跨平台上的优秀实践 五、总结与展望...

3916

扫码关注云+社区