小团队中的Continuous Integration初探

Posted by zhaoguoquan on June 27, 2015

使用Jenkins做iOS持续集成

手工与自动化只是一种形式，真正的核心是测试用例、业务模型和测试分析。

什么时候使用CI 小团队是否需要CI CI的代价 xcodebuild+Jenkins：CI系统初探 参考文章

什么时候使用CI

Continuous Integration（CI）也就是我们说的持续集成。当你希望你的的项目获得以下的好处的时候，你应该使用CI。

  1. 希望获得一个任意版本都可部署的同意代码仓库。这个仓库应该包含了发布Release版本的应用所需的全部资源，并且checkout任何一个版本都可以直接部署至生产环节。

  2. 希望自动化build的过程。一条指令即可完成build-test-deploy的过程。

  3. 希望每次新commit的代码并不对现有功能产生影响。代码实践中经常会遇到新提交的代码影响了某些功能的实现，但是每次提交代码的时候去手工测试各个功能点又是几乎不可能的。

  4. 希望将发现bug的时间提前至开发阶段。传统小作坊式的开发经常包括：确定需求-划分模块-分配给不同的开发人员-合并分支-测试。这种情况下发现的bug可有可能是几周之前写的。

  5. 希望团队所有人能掌握开发的“健康程度”。一个常年绿色的“build：passing”的项目的常常会比一个经常出现failing的项目健康，同时，过多的失败也说明开发人员遇到某些不容易解决的问题。图标

小团队是否需要CI

关于小团队是否要使用CI，网上有不少的争论，但是首先我们需要知道使用CI的会带来什么代价，CI带来的好处是否比代价更多。

CI的代价

学生时代的我们写的大多数程序是连单元测试的都没有的。Deploy这些没有单元测试过的代码构建起来的项目被我们称为“玄学”，因为没准哪里就崩掉了。发布Release之前会动用大量人力进行手工测试。效率非常低。在没有测试用例或者测试用例很少的情况下引入CI是否有用？

Continuous integration can be performed without any test suite, but the cost of quality assurance to produce a releasable product can be high if it must be done manually and frequently.

维基百科中指出了CI的引入并不强制要求Test Suite的存在，虽然这样并不好。

考虑维护运行CI环境跑的测试用例，引入CI的成本包括构建持续集成平台，编写，维护自动化测试用例、对项目新功能的Cover，以及对修改的接口的测试用例的维护。

在非正式的学生团队，刚接触编程的学生写出可运行的程序就已经很开心了，也没有养成写测试用例的习惯。所以这种情况下引入CI也不会有很大用处。因为测试核心是测试用例。无效的用例，用任何方法去测试，都没用。测试代码缺少的历史遗留问题并不是一两天就能解决的，CI的引入并不能在这一点帮助我们。

如果说还剩下一些好处：

  • 用CI的build failed邮件提醒开发同学我们的项目离成熟的项目还有多远。

  • 在缺少测试用例的情况下，预先编写一些UI层的业务测试脚本。测试通常情况下的基础业务逻辑是否正确。通过CI保证这个下限不被打破。

xcodebuild+Jenkins：CI系统初探

https://jenkins-ci.org/

访问jenkins官网下载对应版本的Jenkins服务器。我使用的是MacOS的Native Package。OS X 10.10.3

安装后默认在localhost:8080开启jenkins服务。MacOS的lauchd负责开机自动启动Jenkins，如果是在自己的电脑做实验，可以考虑关闭开机自动启动。使用sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist取消开机自动启动。将unload改为load可以启动Jenkins服务。

[Jenkins->插件管理]安装Xcode integration， GIT plugin，Email Extension Plugin，Credentials Plugin

[Jenkins->系统管理->系统设置]进行Jenkins的配置。需要注意的有这么几个地方。

  • 执行者数量 超过1可能导致多个构建同时执行，可能带来潜在的build失败的风险。

  • Jenkins后台执行的命令的是Jenkins用户，因此你的文件夹Jenkins不一定能读的到，具体看权限了。

  • 所有的CI Project都在~jenkins/Home/jobs/文件夹下。在不同Server之间，jobs是可以拷贝的（但是上一条说的Jenkins的配置就不行了，也可能是我没找到）

  • keychain的路径一般有两个，一个是用户的keychain，在~/Library/Keychains/login.keychain.一个是系统的/Library/Keychains/System.keychain.如果你使用keychain，请注意jenkins需要有能力读到这几个文件。然而一般情况下并不能。可选方案包括拷贝纸jenkins目录，或者使用security unlock掉keychain，或者在keychain指明Jenkins可以访问某条记录。（一般只有build过程中需要Code signing的过程才需要）

[Jenkins->新建]构建一个自由风格的软件项目。需要注意的几点：

  • 构建触发器的Poll SCM 允许你定期检查Git仓库是否有新的版本。如没有新版本则不会触发构建。H/20 8-22 * * *表示每天的8：00-22：00，每二十分钟进行一次检查。

  • 关键的脚本在“构建”中写。常见的命令包括使用xcode插件进行build，或者直接写shell脚本。sudo xcodebuild -sdk iphonesimulator -configuration Debug指定了使用iphonesimulator sdk进行Debug这个配置的build.默认jenkins用户并没有sudo权限，可以将其加入/etc/sudoers中，由于build并不会弹出窗口提示输入密码，因此需要在指定shell路径设置NOPASSWD。（较为危险，并不建议）

  • 构建完成后可以发送邮件给指定人。通过email的插件，我们可以设置不同的trigger，比如success的时候给某个人发邮件，fail的时候给所有人发邮件，或者给最有可能导致此次失败的开发者发送邮件。

关于项目的具体build，以及UI测试，我有空再写。Appium框架可以完成不少UI自动化的测试，目前以及在本地写了一些简单的UI脚本，打算未来集成至CI server中，确保项目每次commit都不会带来类似无法运行的大bug。

参考文章

https://en.wikipedia.org/wiki/Continuous_integration#Best_practices

http://www.zhihu.com/question/19721142

http://pm.stackexchange.com/questions/6748/should-small-teams-use-continuous-integration

http://stackoverflow.com/questions/11081250/is-there-any-benefit-of-continuous-integration-in-small-dev-teams

http://www.jrothman.com/mpd/program-management/2011/12/is-the-cost-of-continuous-integration-worth-the-value-on-your-program-part-1/