ATS软件持续交付系统的设计与实现

夏芸

（卡斯柯信号有限公司上海测试部 上海市 200070）

持续交付（Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。它的目标在于让软件的构建、测试与发布变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。[1]

城市轨道交通的列车自动监控(ATS, Automatic Train Supervision)子系统,是城市轨道交通信号系统的重要组成，ATS 通过对列车运行监视、自动排列进路、自动列车调整、自动生成时刻表、自动记录和统计运行数据并生产报表、自动检测设备运行状态等实现对列车运行的监视和控制，辅助调度员对全线列车进行管理。[2]随着轨道交通行业的不断发展，ATS 软件的功能越来越多，越来越复杂，同时为了更快的响应用户需求，ATS 软件快速迭代更新的难度也越来越大，因此，为了更好的应对市场和用户需求，迫切的需求构建快速、持续、高效的ATS 软件持续交付系统。

本文介绍了ATS 软件持续交付系统的设计，以及系统的实现，最后介绍了持续交付系统的应用情况。

1 系统设计

软件从开发到交付用户，要进过一系列的流程，包括代码提交到配置库，代码编译、测试（单元测试、集成测试、功能测试），当室内测试通过后，将软件部署到现场。在当前阶段，ATS 持续交付系统的目标是实现“准交付版本”交付流程的高效和自动化。“准交付版本”即是可交付用户使用的版本。

1.1 设计原则

持续交付指软件从版本控制库到用户手中这一过程的自动化表现形式。[3]为了实现上述流程的自动化和高效，持续交付系统的设计原则包括如下几点：

（1）实现软件交付流程的自动化，尤其是构建、部署、测试流程的自动化；

（2）将交付流程脚本化，并由配置库进行版本管理，包括构建、部署、测试；

（3）交付流程的可视化，同时某个步骤的失败能及时的反馈。

1.2 功能设计

持续交付系统的核心流水线如图1 所示，流水线的这几个核心阶段即为持续交付系统的主要功能，另外持续交付系统还需实现流水线管理功能，完整的系统功能如下：

（1）流水线管理，实现流水线的创建、配置、可视化、度量反馈，以及将其它系统统计集成到流水线；

（2）版本控制，实现ATS 源代码、测试平台代码、流水线脚本、文档等的版本管理；

（3）自动部署，实现ATS 软件和测试平台的自动部署，以及测试环境所需虚拟机的创建，网络配置等；

（4）自动化测试，实现ATS 软件的自动化测试，包括接口测试、功能测试和性能测试；

（5）版本发布，实现“准发布版本”的打包，包括软件和配置、以及生成发布单。

2 系统实现

DevOps 通常是指软件行业新兴的专业化运动,是一组文化、流程与工具整合后的统。DevOps 通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。[4]持续交付是 DevOps 的核心工程实践，贯穿软件开发全生命周期。实现了健全的版本控制系统、基于主干开发、自动化构建、自动化测试、自动化部署、每天多次集成和组织级度量等能力，都对软件开发产生正面的影响。[5]

因此，在ATS 持续交付系统的实现策略上，采取了DevOps 生态工具、商用工具、以及自研工具相结合的方式。

2.1 系统架构

在本文的持续交付系统的实现中，采用Jenkins 作为持续集成服务器，采取Gitlab 作为版本控制系统，采用Coverity 进行代码度量和检查，基于Ansible 实现自动部署，采用自研的测试平台实现自动化测试和手工测试，系统架构如图2 所示。

图1：持续交付系统核心流水线

表1

图2：系统架构图

图3：持续交付工作流

2.2 关键技术

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux 机器或Windows 机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。[6]基于Docker 容器技术，实现本持续交付系统的优势在于以下几点：

（2）易于快速的自动部署，持续交付工具链中的一系列工具如Jenkins、Gitlab、g++/gcc 等，均可已标准镜像的方式直接存储在容器仓库中。

（3）快速且节省硬件资源，与传统的虚拟机相比，轻量容器技术Docke 是系统级的虚拟化而不是传统的硬件虚拟化，因此具有更快的运行速度，启动速度达到了秒级，另外也能极大的节省服务器的硬件资源，在一台普通的服务器上同时运行成百上千个Docker容器。

Jenkins 是一个开源的持续集成工具，并支持分布式的部署，Jenkins 在整个持续交付系统的实现中，起到了至关重要的作用。当源代码发生变更，并提交到Gitlab 版本库，Jenkins 将自动触发核心流水线（图1 所示），并在此过程中Jenkins 通过插件集成编译工具链、静态代码扫描工具完成准发布版本的构建。若准发布版本构建成功，Jenkins 会自动触发自动部署流水线，进行ATS 软件，测试环境的部署，此时会根据测试需求，同时部署多套测试环境，同步进行自动化的接口测试、功能测试、性能测试，若上述测试通过，则进入手工测试阶段，若手工测试也通过，则自动生成发布单，以及将“准发布版本”打版本标签。

2.3 实现难点

对于本文的ATS 持续系统而言，测试环节是实现快速、高效交付的主要障碍，其原因在于：

（1）测试环境部署，基于现场实际设备和运营数据，自动部署整个仿真测试环境，包括：ATS 被测系统和软件，联锁CI 仿真，线路控制器LC 仿真、区域控制器ZC 仿真、车载控制器CC 仿真、轨道线路和信号设备仿真、测试平台和测试数据，以及整个网络环境的配置。

（2）自动化测试，自动化测试的一般思路为，在测试用例中描述测试数据和输入条件，各种仿真设备的操作，获取被测对象的输出后与预期结果进行对比，获得测试结果。由于ATS 测试中涉及到众多的仿真设备和复杂的操作序列，大量需分析的ATS 输出日志，故其自动化测试存在一定的难度。

本文持续交付系统针对上述难点，采取自研的方式，开发了ATS 自动化测试平台，基于Jenkins 的插件来实现与持续交付系统集成，其主要功能如下：

（1）模拟ATS 运行所需的各个外部模拟器（如ZC，CI 等模拟设备），并根据测试人员设计的测试脚本模拟出相应的场景运行，模拟图形工作站（GPC）实现ATS 的界面操作的脚本化。

（2）全程记录ATS 界面上的所有控件的状态以及ATS 与外部设备的所有接口消息内容。

其时的士人对山水的迷恋可以说到了痴迷的地步，竹林七贤“登山临水，竟日忘归”，宗炳“每游山水，往辄忘归”，袁崧欣赏“山水之美也……流连往宿，不觉忘返”。类似于这样的记录还有很多。在这种社会思潮背景下，只有山水和游山水的人使人感兴趣，其他诸如节操伦常、忠臣义士等不为人所重。宗炳“眷恋庐衡，契阔荆巫”，当“老疾俱至”时，唯恐“名山恐难遍游”，于是“凡所游历，皆图之于壁，坐卧向之”。这反映出人们不仅喜爱山水，更欲将山水画于纸上，以便能时时赏之。至此，绘画的主题也随之从先前的人物向山水转移。

（3）根据测试人员编写出分析脚本，分析记录数据，实现结果的自动判定，并生成响应的测试报告。

2.4 持续交付工作流

本文的持续交付系统基于Jenkins 为核心，实现的持续交付工作流如图3 所示。开发人员提交代码后，Jenkins 自动触发后续的流程，并将每一步骤执行的状态反馈给开发和测试人员。另外，测试平台的代码也维护在Gitlab 代码库中，同样也配置了持续集成流水线，完成测试平台的构建和测试平台自身的测试工作。

3 应用情况

本文的持续交付系统经过了3 个多月的试用，从实践的效果看，在以下几方面有所提升。

3.1 发布成本降低、周期缩短

表1 是近期平均一次完整的“准发布版本”交付流程的周期和成本的对比情况。交付周期缩短了27%，人力成本减少了29%。开发效率的提升主要在于，当前具有一致的开发和测试环境，且开发和测试环境可以快速的多套部署，大大减少了环境不一致和环境紧张而产生的时间成本。测试效率的提升主要在于，自动化测试的投入，缩短了周期且降低了人工成本。

3.2 质量提升

持续交付的理念是内建质量，软件质量由整个团队负责，尽早的发现缺陷并尽早修复。本文的持续交付系统，通过标准化和自动化的手段，针对每一次代码的变更，进行验证和缺陷的快速反馈。从近期的使用效果看，代码质量有了一定程度的提升。

4 结束语

本文将DevOps 生态工具链和自研自动化测试平台相结合，实现了适用于ATS 软件的持续交付系统。该系统能有效的提升开发、测试团队之间的协作效率，提升代码质量，降低开发成本。在下一步的研究中，计划将本持续交付系统与公司私有云结合，构建“端到端” 交付流水线，贯穿从用户需求到最终的版本发布，实现持续交付全流程的可视化管理，持续度量改进交付流程。