题图： 本次技术沙龙合影

演讲 | 麻袋财富_祺超

编辑 | 好买财富_雷文津

在上一期分享中，我们介绍了 好买财富.面向互联网金融的持续集成实践之路，今天向大家展示【金融企业 - 持续集成专题】的第二篇，麻袋财富在持续交付上的实践之路。

-- 演讲内容 --

下面是整个PPT中的28页核心部分，通过口述化的文字进行了编辑整理：

今天我的话题就从业务开始： 麻袋财富主营P2P业务，是服务于投资人和借款人之间的中间撮合平台。

我们的系统涉及到风控，募资，交易，存管等相关模块。(PS：有存管还是挺安全)。

我们的系统演化可以分为3个阶段： 

• 2014年，早期系统是满足P2P核心业务的MVP单体系统。

• 2016年，系统应用随着业务增长快速扩张。

• 2017年-2018年，我们开始做架构治理： 包括业务合规化、应用微服务化、技术栈标准化。

关于技术栈标准化，我个人认为非常重要，因为我们在持续集成的过程中发现有千奇百怪的应用，严重影响了持续集成实施，所以我们会做技术栈标准。

说完了业务系统，接下来我将围绕持续交付来展开后面的话题。

什么是持续交付呢？ 上图我们可以看出，围绕着业务，产品、开发、测试、运维一起协作，快速为用户创造价值，才是持续交付。

持续集成主要涉及开发和测试；而敏捷则会涉及产品、开发、测试。

我们来看一下早期的软件交付方式： 瀑布模式。

举个栗子，阿姨做饭的套路就是瀑布模式：先买菜，再洗菜，再炒菜，最后一起上菜。 我想尽早先吃一个菜，然后来参加会议，她是无法实现的。

瀑布模式的缺点就是：整个过程周期长，没办法满足需求。

然后，有的人提出了一种新的模式，在开发/测试阶段分成许多的迭代。

那么这种方式算敏捷么？ 显然不是，因为中间过程并未交付给用户，没有为用户产生价值。

来看一个敏捷的实例： 早期我们只提供了P2P的散标业务模式，一般一个借贷合同都是3-5万，而当他的资金较大的时候，需要重复购买许多次，非常麻烦。所以我们就给用户做了自动投标工具。

我们在做的过程中，首先确定需求的优先级： 一是核心需求 - 自动投标；还有就是基本需求 - 还款；另外还有扩展需求 - 复投；

所以，基于需求优先级，我们分成了3个迭代，分别上线，每个迭代都为用户带来了价值。

在过程中，我们还做了交付可视化，早期的敏捷看板基于黑板，后来衍生成基于JIRA的敏捷看板，同时也做了很多具体数据的分析；

关于敏捷交付方法的心得，我想分享以下几点：

1. 要善于抓住重点。

2. 团队要定义清晰的目标。

3. 要与业务方计划保持一致。

还想说一下站会，不做流水账的汇报，不说需求。

刚才我们聊了交付方法，那么对于开发人员来说，就想着我要去写代码了。

写代码就要有分支，那么我们怎么选择呢？

早期，我们使用主干开发的模式。契合持续集成思路，但并发支持性不好。

接下来讲讲我们团队现在正在用的GitFlow分支模式。它很好地支持了业务并行。

还有另外一种玩法：分支开发模式。

虽然业务的模式使我们不能选择TBD的分支模式，我们还是基于GitFlow的分支做了持续集成支持，针对每个分支建立持续集成流水线。

分支管理上做了很多事情（如下图），尽可能的往持续集成方向靠。

关于持续集成的配置管理，早期我们配置和应用放在一起，分别维护多套环境的配置，一起存放在git仓库中。

后来，我们基于携程apollo做了分布式配置中心。

通过启动时拉取的方式加载配置实现热更新，通过配置中心实现环境支持及版本管理；另外还做了配置的分级，区分了全网配置、应用配置等等。

除了配置，还有数据库变更。

早期我们都是开发自己维护测试环境，上线时，由开发负责人进行汇总并提交工单给DBA，再由DBA负责操作。常常发生的问题就是上线后发现系统报错，因为这种模式容易发生脚本的遗漏或脚本执行顺序不一致。

基于以上的问题，我们做了数据库变更自动化工具。逻辑是：开发按照约定的规则将变更脚本提交到git仓库中，由CI server来打包生成可执行文件并控制脚本变更到相应的环境。在这过程中也和配置中心打通，并做了一些check。

实现了自动化变更、回滚等操作。同时，有了这些自动化的支持，测试阶段的数据初始化等变得极其便利。

为了做数据库自动化变更，我们定义了许多规范，比如： 禁止先删再加，修改大表需与DBA提前沟通；重大变更需要有回滚脚本等等。

上图是我们的持续集成流水线，包含了单元测试、静态扫描、部署、测试等环节。借用了Junit，mockito，Jenkins，docker等工具。

我们先来看看流水线1.0：早期的流水线时根据应用、为不同的分支/环境独立创建的，可以看到我们job非常多（这里仅展示了冰山一角）。

这就造成我们维护成本非常高，通常是改一个功能要动一大批job。

然后，我们基于jenkins的pipeline做了持续集成2.0：

将pipeline的脚本也放在git中维护，实现了统一维护、批量修改。

同时将很多属性做了参数化，这样就能支持不同分支版本、不同应用的持续集成运行了。

这是我们的流水线脚本，我们针对原子做了默认流水线，也开放接口给不同的开发团队，允许他们进行自我编排流水线。

我们来看看不同阶段(不同环境/不同分支)下流水线有哪些差别。

首先在功能测试环节会更偏向于部署加手动测试，而在集成测试阶段会要求部署加自动化测试，等等。可以看到每个阶段侧重点和频率都大不一样，而我们的流水线，也做了相应的支持。

接下来我们来看看测试。

持续集成的本质是为了保障代码的质量，而代码质量的体现，除了开发自测，主要是通过测试来验证。

我们早期的测试现状是：每个团队的测试框架不一样，技术栈也不一样，相互之间不可共用；测试用例随着框架，都在每个测试人员手中，无法进行统计和管理；这样就造成了每次测试都只能由同一个人执行，换个人可能跑不起来。

这就是我们早期测试碰到的问题。

为了改变这样的状况，我们做了持续测试平台，围绕着测试开发，增加了测试计划，测试任务，测试报告等模块。

我们修整了测试开发框架，形成了统一的测试用例库，基于测试用例库，做了测试集和测试计划，并打通了pipeline；

另外，基于测试计划，我们还做了任务调度及日志管理；最后还做了统一的测试报告；这样就形成了完整的测试平台。

这是我们测试平台的技术架构，可以看到我们的微服务管理和K8S容器管理，我们都在尝试着用，目的是为了拥抱新技术，这是一种新趋势。包括Kubernetes，OpenFaaS等。

这是我们测试平台的一些展示，测试用例/测试计划/测试报告等。

接下来，我们聊一聊各交付阶段的质量要求。

FAT环境主要用于验证功能，一般情况下都是基于mock进行测试；SIT环境主要执行集成测试计划，也会包含性能测试；等等等等，这里不多说了。

我总结一下持续集成的心得，首先持续集成的本质是保证质量，然后要单元测试（我发现要定期给研发人员培训），要避免依赖，要做本地构建，构建失败要第一优先级处理，等等。

接下来我们谈谈持续发布，首先来看看我们的上线关卡，分环境关卡和测试关卡。

这是我们的发布系统，发布系统与JIRA打通，取得发布工单，运维通过UI操作。

我们现在正在做CMDB，将对接我们的发布系统。连接配置中心，制品库和监控告警，通过Ansible和Shell发布到IDC。

这是我们的部署流程，简单说一下几个环节：

1. 发布过程要关闭监控，如果监控不关，会收到一堆短信和电话轰炸。

2. 检查是否停止，这里和应用启动后，调用的都是健康检查服务。

3. 完成后要发送部署通知，告知相关人员。

发布策略我们主要采用灰度发布策略（时间关系，这里就不展开了），通过配置滚动发布，这样对用户的影响最小。

最后，我们谈一下后续规划，我们的（鲁班）Devops平台。

我们希望开发一套各种各样的工具/平台给开发、测试人员用，以帮助他们解决日常碰到的问题。

目前正在做CMDB这一块，主要围绕基础资源、应用资源、逻辑资源。以应用为中心，管理相关的基础信息，并为上层提供接口服务。

这里不再细述了，今天先到这里。

| PPT下载

【运维篇】 - 麻袋财富.持续交付实践之路 | https://pan.baidu.com/s/1qVH2f9opVPHq-oxnpcMTSQ

【测试篇】 - 好买财富.面向互联网金融的持续集成实践之路 | https://pan.baidu.com/s/1fBNMx-g38_Sh4L2Lb2v2jQ

-- 演讲视频 --

感谢您的阅读

您的支持是我最大的前进动力

- End -