公司做的是产品化的APP，然后这个APP可以变成很多项目化的APP。具体大致就是替换下图片啦，颜色啦，用不同的配置文件，就可以重新封装成一个新的APP然后给人使用。

一个产品化的APP衍生出各种逻辑处理相同，外观不同的APP。

一 . 构建

所有衍生品的项目其实都出自一份代码，只是资源文件，及配置信息不同。

面临问题

1.1 数百家项目，如何只维护一份代码。
比如，一个项目里测出有一个bug，意味着，所有项目中都存在着bug，如果每个项目有一份代码，那么100个项目，同样的bug就要修改100遍

1.2 不同的项目个性化的需求如何合理解决。
每个项目或多或少都会有不同的需求，如何在不写死代码的情况下解决。

研究过程

解决问题1.1的研究过程
初期调研过很多方法，从最开始每个项目拷贝黏贴一份新的代码出来进行打包配置，到尝试使用多target的方式进行维护。通通都不行，第一种方式不用说，最简单，也是最没用的。第二种方式，只能适用于只衍生出数十个项目产品，要是数百家的化，那么也是维护不过来的。

解决问题1.2的研究过程
初期，写的是硬代码，一家项目有这样的需求，代码是从一份源码中拷贝出来的嘛，那么就直接改改代码咯。再然后就是通过各种ifelse判断，也是写死的。

方案

排除了拷贝代码，及多target方式，最终采用的方式是，通过本地配置文件及服务端配置参数结合，一个项目有一份配置文件，可以实现多样化，图片资源也是进行替换。项目功能肯定是可插拔式模块化的，具体是通过CocoaPods管理本地库的方式实现。如此这般，数百家项目，只对应了数百个配置文件，通过不同的配置文件，生成对应的ipa包。

二. 打包

采用上述方式进行设计APP产品，在项目化的时候，就会面临一些麻烦的事情。

面临问题

就是替换各种资源图片，修改配置信息。而且涉及到多个部门的配合分工。也就是说，如果需要得到一个新的衍生项目APP，就需要大量的时间，整合资料（从svn中下载查找），然后再做一些重复性的操作，如修改配置信息，拷贝图片资源。并且，这些操作都需要开发去参与，毕竟要操作xcode工程。

研究过程

一开始手动去做这些修改，直接在基线工程中进行修改后，进行打包。这样当然费时，费力。后来，由做了一个打包工具，就是一个mac应用啦，在打包工具中输入各种配置信息，然后把整合好的图片资源导入到打包工具中，即可自动进行打包操作，打包工具内部的实现原理是，通过输入的信息去修改一个模版工程，然后内部用脚本进行打包，上传操作，不过这种方案还是解决不了一个问题，就是整合资源且需要专业开发人员参与。

方案

公司采用svn管理，不过不管用svn还是git其实都适用。

流水线化全自动打包
由于大家都很反感做些重复机械性的劳动。并且，觉的打包这种事情可以让根本不懂代码的人来做。所以设计了一套全自动的方式。

• 整合资源
  这一部分，最费事，公司采用svn管理的方式，那么当收到一个打包任务时，我们就要去对应的svn路径下，去找到各种打包所需要的信息，这些信息都是由不同部门，不同的人上传，所幸的是，每个存放所需资料的路径是相对不变的。如图片资源就会存放于，xx项目／xx图片资源的目录下，接口信息，就会存放在某某项目接口配置.xls文件中。有了这些条件，那么脚本自动化整合的前置条件就满足了。通过脚本（本人采用python脚本），直接访问svn，然后整合资源。创建出满足于app使用的资源文件目录。听起来很简单，其实有点麻烦，就是读取各类存放于svn的xlsx文件，然后生成打包需要的很多配置信息，文件，然后自动拷贝资源到对应目录。

• 生成ipa包
  资源整合完成之后，脚本就可以进行打包操作，具体是先从svn上找到对应版本的tag，然后修改其pod文件。然后生成工程文件，然后进行打包操作。

• 上传ipa包
  ipa包上传svn及iTunes Connect均可由脚本自动化实现。

• 流水化
  由于考虑到需要完全不懂代码的人打包所以采用以下流程。
  发起打包的人上传xls文件到svn对应目录，这个xls文件以项目为命名（可以通过这个名字，找到svn下对应项目的路径）,文件内容就是打包所需要的部分基本信息（其余信息也可以从svn其他目录中找到）。当上传到svn中会，触发脚本（脚本已经部署在服务端，不一定是触发，也可以是定期更新svn），从而脚本便自动执行打包，打完包后就可以上传到svn，及发送邮件告知对应人员。

后记

写的比较概括，具体细节可以邮件or评论交流