Flutter持续化集成上的演进之路

做者：腾讯 - 小德（koudleren 任晓帅）

存在的问题

为了使用Flutter，刚开始的时候为了快速上线，采用将Flutter和Native代码混合开发的模式，具体的工程目录以下：

能够明显的看到工程目录很乱，android目录下有多个代码目录，lib目录下是dart代码，images目录下是Flutter所用到的图片等资源，并且居然还包含了iOS的代码。如此混乱的目录给咱们带来了四个问题：

1. 须要对Native工程进行了大量的改造

为了将Flutter集成到Native工程里，对Flutter和Native的目录和编译脚本都进行了大量的改造，对原来Native的工程影响比较大。

2. 不开发Flutter的同窗也必须得配置Flutter的SDK

由于Flutter的开发须要Flutter SDK的环境，可是团队内并非全部人都作Flutter的开发，若是要求每一个人都安装Flutter SDK的环境，无疑带来了额外的开发成本。

3. 没法作持续集成

由于Flutter编译须要Flutter的编译环境，可是现有的持续集成的环境没有Flutter的环境，使得Flutter没法作到持续集成。

4. 本地编译环境没法统一

由于第三点的缘由，Flutter是本地编译的，但是每一个人Flutter SDK的环境很不容易统一，例如SDK版本的差别或者系统的差别，会致使Flutter编译产物不一致，从而影响现网的表现，出现iOS和Android表现不一致的状况，甚至会由于SDK版本不匹配形成App的crash。

改进开发模式

针对上面的问题，咱们转而采用了以下的开发模式：

1. Flutter工程和Native工程分开

将Flutter和Native剥离，Flutter是单独的工程，Native也是单独的工程，这样从工程上面就将Flutter和Native完全分开，二者互不影响，Native工程不在须要改造，单独打开Native工程也不须要配置Flutter SDK的环境。在Flutter工程里编译Flutter的产物，而后集成到Native工程里。

2. 本地开发，服务端构建

在本地开发Flutter，可是将编译构建的工做交给服务端来作，由于服务端的Flutter SDK的环境是惟一的并且可控的，这样无论有几个开发者，本地环境有多复杂，Flutter的构建都在服务端，保证了Flutter构建产物的一致性。

3. Flutter构建产物自动同步

在服务端触发Flutter的编译，若是编译成功，会自动将最新的Flutter产物同步到Native工程里，保证Native的工程里的Flutter产物是稳定的并且是最新的，能够及时看到最新的更改的Flutter页面。

这里持续集成服务是用QCI搭建的。

改进后的效果

通过以上的改造，工程目录以下：

能够明显看到工程目录清晰了不少，fluttersdk目录下是Flutter的构建产物，对于原来的Native工程来讲就是一个module，flutternew目录下是Flutter的业务代码，flutternew依赖fluttersdk，flutternew也是Native工程的一个module。通过改造，能够达到以下的效果：

1. 实现Flutter对原来Native工程的非侵入式集成

Flutter只是Native工程的一个module，和其余Native的module是平级的，Naitvie也不须要关心Flutter model的环境，对原来的Native工程没有影响。

2. 保证Flutter编译环境的惟一性

由于Flutter的编译都是在服务端进行的，这样就保证了Flutter编译环境的惟一性，iOS和Android都是在同一份代码同一个编译环境下构建的，也就保证了Flutter产物的稳定性。

3. 实现了Flutter的持续集成

Flutter的代码提交以后，会自动触发Flutter的构建，能够很容易知道这次的变动是否有问题，最新的Flutter构建产物也会自动同步到Native的工程里。

结语

通过改进Flutter的开发模式，目前已经实现了对Flutter的敏捷开发和持续集成,实现了多团队协做远程构建产出的模式。