目前客户端和服务端的交互一般做法是通过http请求进行的，服务端处理之后将结果用json串进行返回，因此针对这样的协议在框架工程中添加了对于http的封装，通过这部分可以实现在对于服务端接口的测试，因此在同一个业务的自动化工程中可以进行UI自动化测试，同时也可以进行服务端的接口测试;

　　在这里的另一个问题是任何协调自动化验证的版本和build出来的版本，目前是做了这样一个约定，统一一个地方存储构建之后的版本，build成功后将构建出来的新版本放置在这个约定位置，然后自动化脚本配置执行的app位置是这个约定位置，从而保证自动化运行的app都是新的成功版本，并且不需要通过人工的方式来进行同步;因此在build的步骤中加了一步在每次成功构建之后将构建的结果放置在这个指定位置：

　　然后在自动化脚本的配置中按照如下的方式指定运行的app位置：

　　自动化测试运行需要时间，如果每次在代码提交之后都运行自动化测试验证的话可能不一定合适，同时新版本的更新也不需要每天都更新几次新版本，目前本地的新版本更新基本上一到两天一次比较适合，因此设置自动化验证Job的执行策略是每天定时执行一次;

　　关于更新ipa包：

　　到这里故事走到要结束的部分了，构建了稳定的新版本之后的下一个任务是把新版本发布内测，这个部分定义在自动化验证的Job中，在自动化验证的步骤之后增加一个新的步骤用于上传ipa包，这一步需要内测版本下载服务器提供一个接口或者一种策略来支持ipa的上传和更新，目前本地的内测版本下载服务器的这个功能还在开发中，因此ipa包的更新还是靠手工上传;

　　下一步展望：

　　目前的这个方式不是好的方式，那么如何把iOS的持续集成做的更好，下一步又该是怎么样的呢?在这里说说自己的一点看法：

　　<!--[if !supportLists]-->1) <!--[endif]-->目前这一套的东西游离在kelude的框架之外，而看看Xcode Plugin这些的终实现仍然是使用的Xcode的命令行工具，那么理论上这个应该可以统一起来整合在我们自己的框架之下;

　　<!--[if !supportLists]-->2) <!--[endif]-->目前整个流程中缺少了单元测试的这部分内容，由于本地的业务目前单元测试实施的意义不大因此忽略了这部分内容，在之后客户端形成自己业务SDK之后需要将这一部分补充上来;

　　<!--[if !supportLists]-->3) <!--[endif]-->目前代码的静态检查主要还是依赖于和开发之间的约定，依赖于Xcode来进行，虽然jenkins提供了Clang Scan-Build Plugin插件进行集成，但是目前还没有将这部分内容很好的集成进来，在之后需要对这部分进行补充，同时过滤第三方的问题，而把关注点集中在自己的项目上;

　　<!--[if !supportLists]-->4) <!--[endif]-->目前环境切换脚本，构建和自动化应该可以更好的协调在一起，而不是采用目前这种临时的笨办法;

　　<!--[if !supportLists]-->5) <!--[endif]-->新的内测版本的上传更新可以做到更加的自动化，而不需要在手动的将稳定版本上传至服务器上;

　　写了这么多，更希望的是抛砖引玉，希望收到大家更多的建议和反馈，更希望可以从大家那里学到新的东西，抛弃目前的一些浅显的做法!