前言
「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」提供了一个优秀的 DevOps 环境，持续集成（Continuous Integration）是Devops理念的一种实践过程，同时也是敏捷开发的具体表现形式。对于整个团队来说，好处与挑战并行。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。这里我们着重介绍持续集成过程中的测试自动化（Test Automation）,如果测试没有实现自动化的话，那么整个持续集成是不完善的，同时也不是高效的。因此自动化测试是持续集成过程中的重要一环。
正如你在上图中看到，「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」有着不同的软件自动化交付周期。
持续集成CI
持续集成工作原理
采用持续集成时，开发（测试）人员可以使用诸如 Git 之类的版本控制系统，将更新频繁的代码（或测试脚本）提交到共享存储库（服务器或Gerrit）中。在每次提交前，开发（测试）人员可以选择在集成前对其代码执行本地脚本测试，作为额外的验证层。持续集成服务在新代码更改上自动构建和运行单元测试，以立即发现任何错误。
持续集成通俗点就是指软件个人研发的部分和测试脚本部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。
CI 需要具备这些：
- 全面的自动化测试。这是实践持续集成&持续部署的基础，同时，选择合适的自动化测试工具也极其重要；
- 灵活的基础设施。容器，虚拟机的存在让开发人员和 QA 人员不必再大费周折；
- 版本控制工具。如 Git，CVS，SVN ，Gerrit等；
- 自动化的构建和软件发布流程的工具，如 Jenkins、Drone.io、flow.ci；
- 反馈机制。如构建/测试的失败，可以快速地反馈到相关负责人，以尽快解决达到一个更稳定的版本。
持续集成的意义（目的）
NXOS，全称Next Generation Operation System， 是基于Android系统的车联网操作系统。从驱动、系统、应用层到云端通讯，锚定汽车驾驶舱进行了一系列定制，技术上满足跨设备、跨硬件平台、云管端、开放等特性，产品上为驾驶者提供安全、智能、美观的视觉和交互体验。系统之间依赖度高，但是由于业务的特殊性，迭代速度比较快。如何使各个服务能够快速部署快速测试上线，对测试和研发工程师形成了很大的挑战。我们引入了持续集成的概念，并开始逐步实施。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
持续集成对NXOS车辆网操作系统解决三个问题点
- 提测质量差。如果压缩了开发周期，质量一定是不行的；
- 测试周期长。一旦代码质量变差，测试投入成本就会很高；
- 重复性的工作多；
持续集成，该从何入手推进
持续集成需要整个team都达成共识，按统一好的规则去做同一件事。我们先找了易做的、影响力大的事情去做，划分到团队个人，逐步细化。然后用一个项目去做试点，会得到一些数据，分析和利用这数据进行总结、扩展。
最重要的一环是选择合适的持续集成系统。是搭建私有部署还是选择托管型持续集成系统，关键在于团队运行的基础设施，团队对持续集成系统的资源投入力度。另外，在选择合适的持续集成服务时，还需要考量系统的灵活度以适应公司不同阶段的开发测试需求。
选择持续集成系统只是持续集成应用的其中一步，还需要建立合适的持续集成文化比如代码质量管控、测试文化等。做好持续集成，可为持续交付与持续部署打好坚实基础。
持续集成的实现
提交代码到git gerrit进行代码审查，代码静态扫描，然后单元测试和代码覆盖job会运行，之后编译打包，部署到对应的服务器上。UI、App会运行自动化测试，并修复和分析失败的case。如果有需要再做功能测试，收集功能测试代码覆盖率和系统性能测试。所有系统都做到自动编译、打包和部署。必须覆盖主流程，不断添加测试用例。及时查看覆盖率报告，对于新增代码业务逻辑必须全覆盖。
持续交付CD
持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。
持续交付框架分析
试想想，如果说等到所有东西都完成了才向下个环节交付，导致所有的问题只能再最后才爆发出来，解决成本巨大甚至无法解决。比如，我们完成单元测试后，可以把代码部署到测试环境中,进行更多的自动化测试。如果代码没有问题，可以继续手动部署到生产环境中。当然，持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署。
持续交付的措施与实践
1、“小批量/小粒度频繁的持续部署或发布”；
2、“为软件的开发到发布创建一个可重复且可靠的自动化过程”；
3、“每次修改都能经过一次构建、测试、部署、发布完整高效的自动化验证过程，实现高速频繁验证，快速问题闭环”。
4、可视化：团队中每一个成员对交付过程中的构建测试部署发布等环节信息都能及时接收和处理以保证交付高效协同；
5、反馈：团队成员能第一时间收到问题反馈以便尽可能快的修复；
6、持续部署：打造持续交付流水线，保障每一个版本的应用程序可以快速部署到任意环境中。
持续交付的目的
持续交付的目标是让软件在短周期内产出，确保软件随时可以被可靠地发布，目标是持续产出可以可靠发布的软件。我理解持续交付需要依赖于持续集成，在持续集成的过程中，通过了所有测试case并且可以正确发布的集成系统，就可以作为持续交付的结果。持续交付与DevOps的含义很相似。持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
持续交付的优点
持续交付和持续集成的优点非常相似：
- 快速发布。能够应对业务需求，并更快地实现软件价值。
- 编码->测试->上线->交付的频繁迭代周期缩短，同时获得迅速反馈；
- 高质量的软件发布标准。整个交付过程标准化、可重复、可靠，
- 整个交付过程进度可视化，方便团队人员了解项目成熟度；
- 更先进的团队协作方式。从需求分析、产品的用户体验到交互 设计、开发、测试、运维等角色密切协作，相比于传统的瀑布式软件团队，更少浪费。
测试环境的演变
第一阶段：需要手动编译、打包、部署。解决方案就是引入jenkins自动化编译打包部署。
第二阶段：服务器硬盘打满了，一台机器上部署的服务太多，服务停止。我们做的就是定时清理硬盘空间，监控服务状态，自动重启服务，保证总体服务可用。
第三阶段：主要问题是分布式服务之间调不通。是因为迭代速度快，开发在本地调试，随意修改本地配置文件。组名不对导致调用不到服务。
APP测试自动化---Automated Test
自动化测试（Automated Test），很多团队都在做，但是往往效果不明显。究其原因还是对自动化测试的理解误区, 以为有了自动化后，就不需要手工测试了，因此将一些不适合做自动化的测试用例进行自动化，导致了投入产出比过高。同时，由于缺乏好的统一的测试框架支持，自动化测试脚本编写的复杂度过高，维护性差，耗费了测试人员大量的精力来编写和维护自动化测试用例。
基于项目实际，我们在自动化测试实践过程中，选择了一款验收测试自动化测试框架Appium，结合python unittest来作为我们的核心框架。同时基于Appium框架，构建我们整个可维护性可扩展性的自动化测试套件架构。
APP自动化测试在持续集成中也遇到了一些问题：
1.针对网络不稳定失败率高，我们引入了重试监听，如果重试3次还不能通过，那就是有问题的；
2.不容易定位case失败，我们加入了截图和log日志功能并集成成邮件形式发送report，多打日志加截图，就能发现整体的问题所在；
3.还有就是运行速度慢，android可以启动多个服务，分布运行；
