Original address: http://www.csdn.net/article/2015-05-26/2824771-continuous-integration-deployment-for-ios-projects
When implementing new features, ignoring maintainability and introducing technical debt will either need to delay its resolution or result in increased maintenance costs.
Recently we've been thinking about ways to improve the quality of our code:
- When the quality of the code drops, by setting up some tools to immediately alert the developer;
- Document some coding conventions and think about how to avoid poor maintainability issues over the past few projects.
I'll briefly outline what we need to set up to automatically monitor code quality.
Base
We chose a continuous integration tool , Jenkins , to run on a Mac Mini in our studio. Actually I don't really like Jenkins, but by far it's the most stable and suitable tool for these jobs.
We have installed Jenkins and Ruby via Homebrew and rbenv respectively, and rbenv provides us with an up-to-date and stable environment for Ruby Gems . With Homebrew and Ruby Gems two package management tools, we can install almost all the tools we need, but rarely break the Ruby provided with the original OS X system update.
unit test
We use Specta and Expecta to test our iOS projects.
Specta lets us write tests in a Behavior Driven Development (BDD) style syntax, which is more readable than XCTest's syntax. It also has a powerful group testing feature that runs some code blocks before or after the test, which greatly reduces duplication of code.
Expecta is a matcher framework that we can use in our tests to create assertions. Its syntax is very powerful, and at the same time, it is more readable than the built-in XCAssert suite. E.g:
expect(@"foo").to.equal(@"foo"); expect(foo).notTo.equal(1); expect([bar isBar]).to.equal(YES); expect(baz).to.equal(3.14159);
When we are developing, we run tests through XCode; when using Jenkins installed through Homebrew, we will use XCTool . XCTool is an alternative to xcodebuild that allows you to run test suites and generate JUnit-style test reports very easily from the command line.
$ xctool -workspace Project.xcworkspace -scheme Project -reporter junit:junit-report.xml test
These test reports are published on Jenkins, and Jenkins uses the JUnit Plugin to provide graphs of unit test results over time, while showing us whether our tests are stable or not.
Unit Test
Pull Request Test
We want our tests to run as long as possible so that if we break something, we'll know right away. We make some changes in the feature branches , then submit a pull request to Github, and the code will be reviewed by another developer. Once opened, we can run all the tests to make sure nothing is broken.
To manage these when new pull requests are open, we install the Github Pull Request plugin to send information from Github to Jenkins. If any test fails, it will show up on Github, then we don't merge the code until the code is fixed.
code coverage
We will also use the Gcovr tool to generate code coverage reports. Gcovr is also installed with Homebrew. You need to change two build settings for the main target's debug configuration to configure the project. Set both Generate Test Coverage Files and Instrument Program Flow to YES.
Code Coverage
When we run unit tests to generate code coverage reports, we need to add OBJROOT=./build to the end of the XCTool command line.
$ gcovr -r . — object-directory build/Project.build/Debug-iphonesimulator/Project.build/ Objects-normal/x86_64 — exclude ‘.*Tests.*’ — xml > coverage.xml
Code coverage reports output by Gcovr are also published by the Cobertura Jenkins plugin , which provides a visual way to show code coverage over time.
Now we can see not only whether the test passed or not, but also the test coverage of the code.
static analysis
In the toolset, one of the powerful tools that can maintain high quality code is static analysis tools. These tools scan your code and generate a report that tells you where code is breaking code style rules. Here are some examples of rules:
- unused variable or parameter
- long variable names, method names or lines of code
- Override a method without calling super in this method
- 方法太长或方法过于复杂
- 还更多的规格...
我们使用OCLint静态分析工具，这个工具能够支持C，C++和Objective-C语言。OCLint通过结合XCTool使用来生成json-compilation-database reporter，从而提供great integration特性。我们首先添加另一个reporter到我们的XCTool命令行，然后将那个report传递到OCLint来执行静态分析。
$ xctool -workspace Project.xcworkspace -scheme Project -reporter junit:junit-report.xml -reporter json-compilation-database:compile_commands.json test $ oclint-json-compilation-database -e Pods -report-type pmd -o oclint-pmd.xml
这个report以PMD的方式来生成，然后使用PMD Plugin被发布到Jenkins。有了这些插件之后，你也可以在测试失败之前，设置每个警告的优先级(底，中，高)中一些限制。最初，我们设置这些限制为低，那么只要我们引入代码，就会被提醒，从而提高代码质量。
Static Analysis
自动部署
最后一个问题不是如何提高代码质量，而是如何节省时间。开发者通常都会将编译好的代码通过Crashlytics发送到设计师来设计审查，或在sprint结束演示时发给用户。发送一个已经编译好的App通常花一个开发者的10分钟左右时间，但它需要他们来切换任务和干扰他们的心流。
最近我们已经配置一个在夜晚构建系统，它会在早上自动发送一个新版本的App给每个人。
为了做到这样，我们使用fastlane。fastlane是一个定义lanes的一些操作来执行的强大工具集。现在我们有三个已经定义好的lanes，一个是用来发布给ribot开发者，一个是用来发布给在ribot的每个人，最后一个是发布给用户。
before_all do |lane|
cert
sigh
end
desc “Deploy a new build to ribot iOS developers over crashlytics”
lane :dev do
ipa
crashlytics({ groups: ‘ribot-developers’ })
end
desc “Deploy a new build to people at ribot over crashlytics”
lane :internal do
ensure_git_status_clean
append_build_time
ipa
crashlytics({ groups: ‘ribot’ })
reset_git_repo
end
desc “Deploy a new build to everyone over crashlytics”
lane :external do
ensure_git_status_clean
increment_build_number
ipa
crashlytics({ groups: [‘ribot’, ‘client’] })
commit_version_bump
add_git_tag
push_to_git_remote
end
after_all do |lane|
clean_build_artifacts
end
通过使用fastlane工具(通过Ruby Gems来安装)来运行一个lane。
fastlane internal
在开始使用所有的lanes之前，我们应该自动确保我们有一个有效的signing certificate和最新的provisioning profile。所有我们的配置都放在一个.env文件，它让我们有些默认配置，但当我们运行fastlane根据需要来覆盖它们。
在将来，我们会通过使用deliver操作来自动化App Store提交过程。
最后总结
到目前为止，我们已经尝试这些过程，并在工程中呈现出好的结果。我们期望看到只要适当地使用这些工具，就能提高代码的质量，这些报告将会让我们随着时间推移来量化代码质量。我们期待在下一个工程中适当地使用这些工具会发生什么。