从交付到持续集成交付——随需应变的政务应用前端框架

传统流程交付模式

传统流程交付模式，又称为瀑布开发模式。政务系统交付过程是从系统需求分析开始，历经设计、后台开发，最后进行评估实施。这种交付方式是无持续集成的交付模式，存在以下问题：代码集成很困难，所有人都在同一个仓库上工作，每天会有很多的代码提交和冲突。

测试难，依赖性高。当我们的软件部署到测试环节的时候，测试需要将所有的需求一一测试。

持续集成交付模式

持续集成交付模式即敏捷开发模式。系统敏捷开发模式以架构为中心，以需求为驱动。通过架构，确保软件的可扩展性和接口合理性，强调接口设计，方便于迭代和合作开发。其具有交付周期短、测试完备、测试完备等特性。

对比可以看到持续集成是以小步快跑的方式进行迭代交付，瀑布式是以时间为轴的线性交付。此外，持续集成和瀑布式相比还有不同之处：

第一：快速发布。持续集成发布更加快速，能够及时得到用户的反馈以进行下一个版本的迭代，调整优先级，调整需求。

第二：由于测试的提前介入，它能保持测试的稳定性。

第三：由于我们能够持续地看到成果，对项目的管控更有直观的感受。

最后：团队协作的提高。因为在持续之前的环境中，不同的角色沟通更加频繁，所以持续集成的团队协作相对于瀑布式的任务交接的方式会有更好的提高。

随需应变的前端框架

随着政务系统复杂度的直线增加，对业务的随需应变成为交付最大的难题。采用持续集成的开发方式后，我们采用前后端分离的架构，前后端通过契约描述自己的接口，通过Restfull API进行沟通。这种分离方式不仅可以降低服务器压力，开发团队协作分工也更加合理。后端专注于数据和服务，前端专注于功能开发和交互。基于这样的要去，结合业务应用场景，数慧设计了一套政务前端框架，并附带了一些脚手架工具，搭建了灵活的模块化仓库。

模块化

框架基于流行的angularjs框架，从样式到页面布局再到功能模块是按照模块化的思路进行划分。这样我们可以像玩乐高玩具一样随意的对页面样式布局功能等进行更改，重新组装优化，保证可以快速的满足需求的变化。

组件化

项目中经常用到的模块会抽象成组件，组件会被积累到私服中，所有项目公用，保证有持续的资产积累，快速的响应需求。

规范化

我们建立了编码规范、前后端接口规范、视觉设计规范，并且会定期codeReview，以此来保证代码的质量。

以下为设计规范图样：

以下为后端API导航：

以下为前端开发规范：

价值交付

自动化构建，持续集成

框架采用前端流行的构建工具，可以自动化的进行代码的构建、版本发布。开发过程可以实时刷新等来保证开发速度。

高性能

采取按需加载、字体图标库、缓存更新、缓存共享等方式优化前端性能。

基于前端框架，面对新的项目需求，可以让开发人员快速的搭建起开发环境，并引用到以往项目沉淀的模块化资产，快速的进入迭代开发状态。

下一阶段挑战

监控和日志

监控日志对于产品性能是非常重要的，尤其是前端大量运用js后，时刻监控浏览器日志信息，可以知道产品的问题，潜在的错误，用户使用软件过程中遇到的问题等，可以进行准确的定位。日志在后端平台是有记录的，但是针对前端用户访问过程的js错误等等的记录还比较少。也没有做这方面的分析。数慧认为软件的交付不是软件开发的终点，而是起点，我们可以从日志数据、用户使用情况习惯等等来挖掘用户的需求，完善我们的系统。

自动化测试

目前产品还是只专注于业务功能的开发，测试自动化覆盖率不高。后续将更多引入自动化测试方法和共计，保证在持续集成过程中的代码质量，减少人工工作量。

转载声明

如需转载，请在开篇显著位置注明作者，并注明出处（转自：DIST上海数慧）或在文末附上DIST上海数慧醒目二维码；

无原创标识的文章请按照转载要求编辑，可直接转载，转载后请将转载链接发送给我们；

有原创标识的文章，请发送【文章名称-待授权公众号名称及ID】给我们申请白名单授权。