魏名华

不要偷懒,做更好的自己

Nothing


No Welcome Message

Ci&cd

喵大 能不能详细讲讲CI在我们实际开发中发挥的作用(尤其是对我这种没有什么开源项目,也不和谁合作自己独立开发的),以及具体要如何使用。(上次直播本来想着重听一听的,结果没怎么说。。)(这算不算具体技术问题)

onevcat 2017-04-01 22:25 回答 首先实在抱歉,之前的直播因为时间上没有掌控好,导致收尾​有些匆忙,所以这部分几乎只稍微提了一下。不过因为直播的重点其实也并不是 CI 这部分,所以可能在这边详细回答一下会比较好。

首先 CI (continuous integration) 其实是一种自动化的方式,也就是说,是帮助我们保证某些事情执行的手段。在这里,也就是对项目进行构建和测试。​你提到自己不做开源开发,也一般是个人独立开发。这种情况下 CI 的价值确实会小一些,因为你可以自行保证开发环境。不过即使是这样,CI 也能够在开发过程中减轻你的部分压力。我会先综述一下对于一个开源项目或者和别人合作的项目中 CI 的意义,然后再针对个人独立开发时 CI 可能发挥的作用来进行回答。

首先要明确的是,在一个提供给别人使用的开源项目里,完善的测试一般是不可缺少的。可以说只有具有完善的测试,你的项目才能获取别人的信任和关注。CI 配置一般会在你 push 之后就自动进行构建和测试,这保证了测试运行的次数。比如你在本地开发时很可能改动后忘了进行测试就 push 了,或者是其他贡献者进行开发向你提交 pull request 时可能也并没有预先运行测试。如果代码中存在问题,导致测试无法通过,或者甚至是不能编译,那么 CI 就可以保证在第一时间找出问题,你也有机会只用对比极少量的代码和 commit,并更快地找到问题所在。而潜在的贡献者也能够通过这样的验证来知道自己的修改有没有对项目产生破坏,并且如果在测试无法通过的时候自行进行一些修正,也节省了互相沟通和交流的时间成本。

除了保证测试运行次数以外,CI 另一个常见作用是可以为我们验证不同开发环境下项目的情况。我们可能很少会去在本地安装多个 Xcode (其实不限于 Apple 开发,也同样适用于其他开发环境),即使是安装了多个 Xcode,也基本不太会修改一些代码就轮流打开各种版本的 Xcode 去跑测试。类似地,我们在测试的时候也往往不太会去遍历所有的系统版本。人为运行的测试或者调试就面临着这样的问题:你很难持续地把所有的情况进行覆盖,比如某个功能在 iOS 10 下可以正常工作,但是在 iOS 9 中就有问题;某段代码在 Swift 3.1 里可以正常运行,但是在 Swift 3 里却无法编译。这样的问题要在开发中随时监测的话,成本非常大,而且极易出错。因此,如果有这样的需求的话,使用 CI 将这个过程自动化,是很有必要的。现在为开源项目提供 CI 支持的做得最好的应该是 Travis CI,它们就提供了很方便的叫做 matrix 的功能,你可以很简单就定义出一些组合的集成环境,然后将这件工作进行自动化处理 (当然,其他一些 CI 平台也有类似的支持)。关于这方面的例子,可以看一下 Alamofire 的 travis 配置文件,他们就使用了 matrix 定义了很多设备进行测试,来保证在不同系统版本中项目的正确性。

​对于个人的 app 项目来说,可能并没有多开发环境的需求,项目基本只会运行在统一的自己的开发环境里,但是多设备系统的测试还是有可能的。另外,个人项目来说,相对于使用 CI 进行构建和测试,更有可能用到的也许是持续交付 (continuous delivery, CD)。特别是如果版本发得勤快的话,其实每次编译,archive 打包,上传 TestFlight,提交 App Store 等过程也还是十分繁琐的。像是更新版本号啊,修改 app 截图啊,修改 release note 啊,都人为做很有可能出现失误的情况,而且繁琐程度往往会让人厌倦心烦。一个良好的做法依然是将这些流程自动化处理,其实就是 CD 的概念。当然 CD 不一定要架设在某个服务器上,用本地开发环境进行自动化的提交也是没问题的。这里还是要推荐一下 Fastlane 这个项目,它提供了非常多很方便的 action,让 iOS 开发自动化变得十分简单。

​总得来说,如果你是在做供别人使用的开源项目的话,一套良好的 CI 是你的项目能长久地活下去基础。如果你是单枪匹马的话,虽然 CI 环境不是必须的,但是有一套帮助开发和确认项目正确性的验证系统,以及一套自动化减轻周边工作的流程,可以让开发的时候更专注于重要的东西 (核心功能和逻辑之类的),也是很有好处的。唯一的担忧其实在于在不熟练的情况下,初次架设和使用 CI 环境会花一些时间,不过我认为在这上面进行一些投入是完全值得的,因为你能够获得完全不同的开发态度和开发体验。而且后续的 CI 设置几乎都可以照抄原有配置,而不太需要重复投入,可以说是一件性价比很高的工作。