iOS系统下的持续集成实践(2)

　　Xcode Plugin可以构建ipa包，因此在这一步可以将正式环境的内测ipa包生成出来;

　　<!--[if !supportLists]-->4) <!--[endif]-->自动化验证;自动化脚本验证之后的版本就是稳定版本，可以提供给外部进行内测，因此自动化脚本要求覆盖应用的主要功能点，保证这些功能点的功能正确性，注意自动化验证的版本的环境一般是测试环境;

　　<!--[if !supportLists]-->5) <!--[endif]-->内测版本上传;自动化验证针对的是测试环境，在自动化测试通过之后将相应的正式版本上传至内测应用下载服务器，该步骤需要和服务端约定一个更新的规约，如果没有规约则需要手动上传，注意如果没有办法自动上传需要将稳定版本进行存储;

　　上面说了本地生活在这两个iOS客户端测试中遇见的问题和一些解决办法，整理了一个大体的思路，那么在后面的部分针对每一部分进行详细说明，聊聊现在本地的做法，也说说自己的思路;

　　说说实践：

　　关于代码更新：

　　代码更新没有什么好说的，需要进行代码更新的有两个地方，一个是在每次build之前使用更新代码，另一个是在每次进行自动化验证之前更新自动化测试的代码;

　　一般来说工程的svn库和自动化测试脚本的svn库是分开的，所以在这里采用了最简单的处理方式，将整个流程拆开，拆分为2个Job，一个是针对客户端工程的代码库，该Job负责代码的静态检查和build工作，另一个是针对测试脚本的代码库，该Job负责自动化验证工作;

　　关于静态检查：

　　Xcode中集成了Clang Static Analyze检查器，通过该检查器可以对工程进行静态分析，通过分析可以找出代码中存在的潜在问题，如潜在的内存泄露、变量未赋值就使用、变量定义之后没有使用或者除零等逻辑错误;

　　目前为了保证版本发布的质量，减少潜在的风险和开发进行了规约，在每次提交之前对于代码进行静态检查并对检查结果修复;

　　在Xcode中使用Analyze的方式如下：

　　Product->Analyze

　　在上图中的左边栏中的蓝色标示就是存在潜在问题的地方，开发和测试的同学都需要对这些地方加以注意，对于每个问题进行分析;目前本地的规约如下：

　　<!--[if !supportLists]-->1) <!--[endif]-->如果该问题是由于第三方库带入的，或者第三方库的问题在不需要修复;

　　<!--[if !supportLists]-->2) <!--[endif]-->如果该问题发生在非第三方库的代码中，并且确认是一个问题就需要修复;

　　<!--[if !supportLists]-->3) <!--[endif]-->如果该问题发生在非第三方库的代码中，并且确认不是一个问题不需要修复;

　　关于代码静态检查最好是针对iphoneos(最好不要采用iOSSimulator)的Release版本进行静态扫描;在Xcode中可以通过Product->Edit Scheme来进行设置：

　　那是否只能通过Xcode来进行代码静态扫描呢?有没有更加懒的办法来自动的进行这个工作呢?答案是有的，Jenkins提供了一个插件叫做Clang Scan-Build，通过这个插件可以对代码进行静态检查，该插件使用的也是Clang，和Xcode是一样的，该插件最终将生成xml的报告，在Analyze之后可以发布报告;

　　在jenkins中设置如下：

　　在我们的工程中的一些问题可能是第三方引起的，本工程中没有办法进行处理，而这些问题可能会导致认为工程的build版本为不稳定版本，该插件提供一种简单的方式来处理这种情况，插件提供一个阀值，当超过这个阀值的时候才会认为工程是不稳定的版本，这个时候只需要统计出没有办法进行处理的问题数目，然后将阀值设为这些问题的个数;

　　关于自动构建：

　　Xcode提供了命令行工具来通过命令行进行工程的构建，在Xcode4.5中命令行工具是默认不安装的，因此需要首先安装命令行工具，安装方式如下：

　　安装完成之后就可以使用xcodebuild命令来进行工程的构建了;

　　开始的时候工程的构建是通过shell脚本来进行的，后来发现在jenkins中提供了一个Xcode Plugin的插件，通过该插件可以可视化的配置build的参数，这个插件最终使用的仍然是xcodebuild的命令行;Xcode构建的配置如下：

　　这里的配置项的用法和说明在后面的提示中都有包括，那么说说项目中的一些需求，基本上现在的项目测试自动化脚本都是在测试环境运行，然后发布的内测包都是线上环境的，而又不想把这样的工作通过jenkins中的两个Job来实现，因此这里的处理方式是设置了两个Xcode Step，第一个构建测试环境下用于进行自动化验证的版本(上图)，第二个用于构建内测版本的线上环境(下图);

　　两者之间提供脚本进行环境的切换，目前的问题在于由于各个项目的开发不同，因此用来做环境切换的方式也会不同，这样就导致了需要为每一个项目提供一个如下的环境切换脚本：

　　用于在构建测试版本之前把环境切换至测试环境;

原文转自：http://www.ltesting.net