【开发工具】iOS项目工程CI配置

最新推荐文章于 2025-07-21 18:17:35 发布

原创最新推荐文章于 2025-07-21 18:17:35 发布 · 1k 阅读

1 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#ci/cd #swift #objective-c #git #ios

Objective C notes 同时被 2 个专栏收录

37 篇文章

订阅专栏

开发环境

14 篇文章

订阅专栏

本文介绍了如何在iOS项目中设置CI配置，包括语义化提交日志规范、Merge Request通知、代码静态检查（如SwiftLint）、代码编译检查以及Merge Request合入标准。还讨论了CI工具的选择，如GitLab CI与Jenkins的比较。

提交日志检查

按照语义化的提交日志规范，可以同时对 commit message 和 merge request title 做校验。

语义化提交日志规范

Git Semantic Commit Messages

推荐使用Git Semantic Commit Messages，固定提交日志格式，有助于我们成为一个更好的开发者。
格式:<type>(<scope>): <subject>
其中<scope>是可选的。
格式说明：

feat: add hat wobble
^--^  ^------------^
|     |
|     +-> Summary in present tense.
|
+-------> Type: chore, docs, feat, fix, refactor, style, or test.

类型标识的含义:

feat: 新功能（feature），不是针对构建脚本feature，影响线上代码
fix: 修复bug，不是针对构建脚本的修复，影响线上代码
docs: 文档（documentation）
style: 格式（不影响代码运行的变动）
refactor: 重构（即不是新增功能，也不是修改bug的代码变动），影响线上代码
test: 增加测试，或者重构测试代码
chore: 构建过程或辅助工具的变动

如果type为feat和fix，则该 commit 将需要出现在 Change log 之中。

Custom Git Commands

推荐安装如下一系列git命令：Semantic Git commit messages commands。

安装好之后，可以更方便地书写语义化提交日志。

Example（左侧为使用上述git命令后的语义化提交日志书写形式，后者为同等效果的git commit形式）：

git feat "commit message here" -> git commit -m 'feat: commit message here'

git feat -s "scope here" "commit message here" -> git commit -m 'feat(scope here): commit message here'

详见：约定式提交

Merge Request通知

可以配置自动化脚本，在发起Merge Request时自动将团队内部的 MergeRequest 链接统一发到项目群中，通知大家进行Code Review。

代码静态检查

SwiftLint

SwiftLint简介：

SwiftLint是由 Realm 推出的一款开源Swift 代码规范检查工具。该工具默认基于 Github 公布的 Swift 代码规范进行代码检查，且能够兼顾命令行执行以及与编译器（Xcode）集成执行。
SwiftLint利用AST（抽象语法树）进行静态代码分析
目前SwiftLint提供了超100种代码扫描规则，通过配置文件可以实现灵活的配置。

SwiftLint优点：

减少代码冗余，明确代码意图
精进代码，减少代码运行时异常的可能性
让代码变得更加“优雅”，提高代码的可读性

SwiftLint配置：

参考代码规范进行lint配置

变更代码行限制

检查MR中.swift/.h/.m/.mm/.c等源文件的代码行，例如超过500行禁止合入，可以限制每次MR的代码变更规模，让代码得到充分审核。

由于IDE/包依赖管理工具在单次操作导致的行数变更会比较多，且都是自动生成，故不需要算到代码行数计算中。

e.g. 限制代码变更行数为500行

#!/usr/bin/env bash

# input: sourceBranch, targetBranch
sourceBranch=$1
targetBranch=$2
maxChangeLines=500
insertions=0
deletions=0

commitStat=$(git diff ${targetBranch} ${sourceBranch} --shortstat -- '*.swift' '*.h' '*.m' '*.mm' '*.c')
IFS=',' read -ra changeList <<<"$commitStat"

for change in "${changeList[@]}"; do
    if [[ $change == *"insertion"* ]]; then
        insertions=$(echo $(echo ${change} | tr -dc '0-9'))
    fi
    if [[ $change == *"deletion"* ]]; then
        deletions=$(echo $(echo ${change} | tr -dc '0-9'))
    fi
done

changeLines=$(echo $((${insertions} + ${deletions})))
echo ${commitStat}
echo change line count : ${changeLines}

if [ ${changeLines} -gt ${maxChangeLines} ]; then
    echo too large commit check failed, please splite your commit and make sure change lines less than ${maxChangeLines}.
    exit 1
fi

echo too large commit check passed.

静态检查场景

本地代码静态检查

适用场景：
当研发同学每次编译项目工程时，在Xcode工程配置中进行SwiftLint检查。

代码仓库MR静态检查

适用场景：
当研发同学提交Merge Request时，在CI服务端进行SwiftLint检查和变更代码行限制。

代码编译检查

每次提交merge request时自动进行编译检查
只有通过编译检查后，才允许merge request合入

Gitlab CI Build Pipeline:

# 模拟合并后进行编译检查
build_project:
  <<: *only
  stage: build
  script:
    - >
      [ -d PROJECT_DIR ] && rm -rf PROJECT_DIR
    - git clone --depth 20 --no-single-branch PROJECT_GIT_URL
    - cd PROJECT_DIR
    - git checkout ${CI_MR_SOURCE}
    - git checkout ${CI_MR_TARGET}
    - git merge ${CI_MR_SOURCE} --allow-unrelated-histories
    - bundle install
    - pod repo update
    - pod install --verbose
    - xcodebuild clean -workspace PROJECT_NAME.xcworkspace -scheme PROJECT_SCHEME_NAME -sdk iphonesimulator
    - xcodebuild -workspace PROJECT_NAME.xcworkspace -scheme PROJECT_SCHEME_NAME -sdk iphonesimulator

Merge Request允许合入标准

MR中的提交通过pipeline检查（代码Lint & Commit Lint & 变更代码行数限制检查 & 编译检查）后才允许合入
MR中的所有discussion解决之后才允许合入
经过指定的review同学Approve之后才允许合入

CI工具选择

Jenkins作为老牌的持续集成框架，在这么多年的发展中，积累很多优秀的plugin工具，对进行持续集成工作带来很大的便利。

gitlab-ci作为gitlab提供的一个持续集成的套件，完美和gitlab进行集成。gitlab-ci已经集成进gitlab服务器中，在使用的时候只需要安装配置gitlab-runner即可。
gitlab-runner基本上提供了一个可以进行编译的环境，负责从gitlab中拉取代码，根据工程中配置的gitlab-ci.yml，执行相应的命令进行编译。

总体来说，gitlab-ci更简单易用，如果有gitlab-ci达不到的要求，可以考虑使用jenkins。