科技赋能 | 财富科技团队的“持续交付”探索之路
我国正处在以数字化、信息化、网络化、智能化为特征的科技变革浪潮中，德邦证券也在数字化转型的道路上大步迈进中。科技的快速发展，使我们置身于VUCA时代—一个有着易变性（Volatility）、不确定性（Uncertainty）、复杂性（Complexity）和模糊性（Ambiguity）特征的时期。App作为公司面向C端用户的门户，为了快速满足用户需求、不断提升用户体验。同时，开发需求如潮水般涌来时，如何在保证系统稳定的前提下，提高交付的效率和质量，是我们一直探索的方向。
起初财富科技团队采用scrum开发模式，需求被拆解为用户故事，根据优先级被划分到不同的冲刺里，一个冲刺只完成固定数量的用户故事，在这期间不在接受新的内容，大家互相配合专注于一个目标，向着共同的目标冲刺，不被其他外界因素干扰。由于以下种种情况的出现，团队逐渐发现完全按照scrum模式去执行，并不能将交付的效率达到极致。
商业环境瞬息变化，为应对变化抢占先机，需求的优先级也会随之频繁变换，需求插队是常有的；
证券经营机构属于强监管行业，经常会有一些监管类的需求需要完成，而且这些需求大多都是要求在规定的时间内完成上线；
App线上时不时会也出现一些亟需解决的用户体验问题，如果不及时解决可能对后续产品购买和用户留存都会有影响；
市场上热点的出现，为了吸引客户，随之而来的可能是相应的各种活动或者推广，过了这个时间点在去做也就完全失去了意义。
由于以上情况的出现，有时需要终止当前sprint，开启另一个sprint，或者是各组抽调出几名同学来进行新需求的开发，这与scrum的理念是相悖的，这也导致了几次sprint的失败，对团队士气也有一定负面影响。于是，团队也开始探索更加符合现状的敏捷开发模式。
为了能在各种多变的情况下，依然能够保持很好的交付效率和质量，经过一段时间的摸索，慢慢有了更加适应于当下的持续交付方案。方案分为几大部分，将每部分串起来就形成了一个需求的交付闭环。
需求管理
为了能将需求更加灵活的组合，形成不同的上线版本，需求的粒度就不能像用户故事一样粗，要控制在一定人天范围内的相对清晰的内容。需求之间要做到完全隔离，每个需求的上线与否不影响其他需求的上线。财富科技团队与产品同学之间形成了一套需求管理的机制。
根据不同的需求维度，将需求按照大类进行划分，每个大类有自己的编号，如理财相关的REQ[TSW]+【自增编号】+【需求内容】+【版本号】，每个大类里新增需求按照自增编号进行维护，每个需求都有一个唯一的编号。最终每个需求的文档以此格式文件名的word存入SVN进行版本管理。
需求作为以后设计、开发和测试的依据，需求管理中必须注意以下几点：
所有设计开发内容必须与需求中内容保持一致；
所有测试用例的编写与执行也需与需求中内容保持一致；
需求如有变更必须第一时间通知开发、测试相关同学，对相关内容、版本号进行更新；
对于已合并至回归版本的需求原则上不支持变更，变更内容需重新生成需求文档。
分支管理
新的方案中，会同时进行多个需求的 并行开发，为保证上线版本内容准确，就需要对不同的分支进行统一的管理，我们借鉴Aoneflow分支模式，并对其进行一些定制化的改造，形成了一套适合我们的分支模式：
开始工作前，从master创建feature需求分支。从代表最新已发布版本的master分支上创建一个feature需求分支，然后在这个分支上提交代码修改。即每个需求（可以是一个人完成，或是多个人协作完成）对应一个需求分支，所有的修改都不允许直接提交到master。分支以feature/需求编号命名；
通过合并feature分支，形成release分支。从master分支上拉出一条新分支，将所有本次要集成或发布的feature分支依次合并过去，从而得到release分支。release分支通常以release/yyyyMMdd_uat。yyyyMMdd为计划发版日期；
待版本发布完成后，合并相应的release分支到master分支，并在master分支上添加tag。
分支管理示意图
发布管理
基于以上改变，发布的版本内容可以动态的进行调整，版本内容可基于所有测试完成的需求进行组合，版本内容确认后，即可在回归环境以及UAT环境进行验证，验证完成后即可随时进行版本的升级。如果多个版本的内容都是相互独立的，可同时进行多个版本的并行发布。
这种模式就像城际快线一样，每个测试完成的需求就像车站里的乘客，上线的版本就像一列列出站的城际快线，当乘客验票上车后，快线就可以出站了。
这种模式的好处在于任何内容都可以动态调整：
因不可抗力因素无法发车，乘客可以搭乘下一班快线（因不可抗力因素导致此次版本不能发布，需求可加到下一个版本中一起发布）；
当车次不够时，在运力范围内可以增加相应的车次（当有紧急需求时，可在单独版本里进行紧急上线）；
当乘客不适无法搭乘时，已验票乘客可继续乘坐本次快线（上线前如有需求进行调整，只需对剩余需求合并验证后，即可在较短时间内完成新版本的发布）；
可根据乘客的流量进行车次的编排（可根据测试完成需求的数量，来动态调整每次发版的间隔）。
配置管理
要想提升交付的质量和效率，保证各环节无错、高效执行，配置管理必不可少。配置管理是对所有与项目相关的产物，以及它们之间的关系都被唯一定义，修改，存储和检索的过程，保证了版本交付生命周期过程中所有交付产物的完整性，一致性和可追溯性。配置管理是持续交付的基础，是保障持续交付正确性的前提，经过一段时间的摸索实践，团队逐步形成了一套自有的配置管理流程。由此也诞生了一个新的角色，配置管理员，配置管理员对从需求提测到版本上线整个过程中的各个环节进行把控，保证上线内容的一致性和完整性，也是保证上线质量的一道有力屏障。
将整个流程串起来就形成了一套完整的持续交付的方案，只有每个环节无错、高效的执行，才能保证交付的效率和质量。
配置管理流程
近一年的时间里，基于以上方案完成了多个版本的上线，在这过程中也对各个环节不断进行优化，逐步提升交付的质量与效率。
每周并行处理15+个需求，每周平均上线10个需求，平均3个工作日交付一个版本，交付速度行业领先。
能达成以上目标，离不开基础设施的支撑，只有基础能力足够强，才能跑得更稳更快：
多套环境同时在线，目前有开发环境、测试环境、回归环境和预生产环境，保证多个需求可以在隔离环境上进行测试验证，最终保证上线版本的稳定；
自动化部署不断优化，目前测试环境已完成所有项目一键发布上线，涉及H5、Java、iOS、Android，大大缩短部署的时间，支持一键切换柜台、一键配置同步更新等；
配置管理流程改进升级，每个月都有固定同学担任配置管理工作，这期间会对整个流程提出不同的优化建议，使整个流程不断进化，更符合当前现状；
自动化测试引入，随着自动化测试能力的不断提升，大大提升了每次版本交付的效率和质量，每次上线前自动执行所有主要用例，既能节省测试人力，又能保证上线内容的质量；
团队成员配合无间，随着一段时间的磨合，团队内成员高效协作、紧密配合，是交付质量和效率最有效的保障。
该方案随着实践过程中的不断改进以及基础能力的不断的提升，相信在交付的效率和质量也将会不断提升。
技术架构升级，升级旧版技术架构，新版架构是容器化以及服务拆分的基础；新版架构各成熟组件的引入，为线上系统的稳定添砖加瓦；新版架构能提高代码编写的效率，减少代码错误，是提升开发效率和质量的利器。
容器化改造，通过使用容器，可以轻松打包应用程序的代码、配置和依赖关系，将其变成易于使用的构建块。容器可以帮助保证应用程序快速、可靠、一致地部署，其间不受部署环境的影响，会大大节省环境部署的时间，环境的一致性大大提高了开发质量和测试质量。
更多自动化测试工具，UI自动化、流量回放等新工具，是缩短验证时间、提高交付效率的又一神器。
随着以上内容的不断完善，App会以光速进化，每周都有新的变化，逐步成为行业内最好用的App。