很长时间没有更新博客了，恰巧最近在为公司的地图SDK搭建自动编译与发布环境，便顺手记录下来。
这个项目本来我就已经使用Jenkins搞了一个打包的Job了，但因为其它项目陆续使用GitLib CI实现了对测试部门的持续交付，为了统一开发人员的使用习惯，我这边也把这个项目支持了CI。

GItlib CI/CD与Jenkins对比：

相比较来说，Jenkins在使用上灵活性其实更高，因为可以配置许多可选的参数或选项，可以实现更加灵活的打包指令，以安卓项目为例，可以定义出代码分支选项、开发/测试/正式环境选项、渠道选项等参数，让使用者可以更有目的性地进行打包操作。
GIt-CI则在自动化程度上占优，通过编写的yml脚本，在每次创建分支、创建Tag、或每次push代码时，就会触发CI，按照脚本中指定的规则，去执行对应的指令，无需人为启动流程。

前提：开发环境准备

1.GitLib代码仓库

相信关注这篇文章的你一定已经有git项目了，any way，就算真的没有，网上关于安装git仓库的文章也比比皆是，此处不多赘述。

2.GitLib Runner：

GitLib Runner这个东西可以理解成ci脚本的执行环境，或者说执行入口。把某个runner注册在某个git项目上，在git仓库中的内容发生改变时，会触发对应runner，基于宿主系统环境完成脚本的执行。
以linux系统为例，首先安装gitlib-runner，参考:https://docs.gitlab.com/runner/install/linux-manually.html
启动runner：gitlab-runner start
注册到项目：gitlab-runner register
这一步需要按提示输入项目对应的url、token、描述、标签和其它一些设置项，执行器我们以shell为例。
其中项目的url和token可以在gitlib项目的 Settings --> CI / CD 中找到 👇

image.png

image.png

3.安卓环境：

因为我们介绍的是安卓项目的打包，那么安卓应用的开发环境：jdk、android-sdk、gradle，项目需要的话还有ndk，除android studio这种IDE外，在runner所在的机器上也都需要。下载过程略👽
假设我们把这些个东西都放在了 /home/env 目录下

CI脚本编写

现在，你有一个能正常编译调试的安卓项目。
ci在runner上的执行靠的是 .gitlab-ci.yml 中定义的阶段和脚本，这个文件必须在项目的个目录下，下面举例说明一些常用的脚本规则。
下面的例子主要为了展示脚本的规则，只以打包命令为例。

# 在stages标签下可以定义多个执行阶段，名称可以随意定义，在git仓库发生任何变化时，都会按照这里定义的顺序来执行对应的script。
stages:
  - check
  - build
  - publish

# 这是其中一个job，名称随意
check-simple:
  # 该job所属的stage：上面stages中定义的某一项
  stage: check
  # 该job对应的执行过滤器，分支或tag名满足这里定义的规则才会执行script，这里是当master上有代码push或合并时执行
  only:
    refs:
      - master
  except:
    - branches
  # job执行的脚本，根据我们安装runner时指定的执行器类型，这里实际是shell命令，或者是shell脚本文件
  script:
    - echo "empty script - check!"

# 在创建DEV或PROD开头的tag时执行
build-all:
  stage: build
  only:
    - /^DEV_.*$/
    - /^PROD_.*$/
  # 分支上提交代码时不执行，仅在打tag时执行（仅供参考）
  except:
    - branches
  script:
    # 真正的安卓编译开始，建议gradle添加环境变量，或者写全路径: /home/env/gradle-6.6.1/bin/gradle clean ....
    # 现在实际上是在项目根目录，执行打包需要执行的是app下的gradle脚本
    - gradle clean assembleRelease -b ./app/build.gradle
    # 打包成功后，把apk文件拷贝到指定目录
    - cp ./app/build/outputs/release/app-release.apk /home/apks/simple-name.apk

# 在创建PROD开头的tag时执行
publish-simple:
  stage: publish
  only:
    - /^PROD_.*$/
  except:
    - branches
  script:
    - echo "empty script - publish!"
  

按照上面脚本的定义，每当mater分支上有代码提交或合并时，会启动job打印一条 "empty script - check!"，实际上我们一般会在这一步配置sonar cube 或 lint 工具来检查代码。
当建立 DEV_xxx 或 PROD_xxx 名称的tag时，会执行打包脚本，生成apk文件并拷贝到执行目录。
仅在建立 PROD_xxx 名称的tag时，执行完build过程之后，会打印一条 "empty script - publish!"，这里我们一般会编写脚本把apk文件上传到指定的地方，然后通过邮件等方式通知相关人员查看。

在每次触发job执行后，会在 CI / CD 中产生记录，可以看到job的执行结果，点击可以查看详情信息和console输出。

image.png

需要注意的是：local.properties文件中定义了安卓sdk的路径，每个开发人员的配置都不相同，runner机器上的路径也不相同，要保证打包成功，这个文件就需要定死不能提交，或者在执行build前再加一步，替换掉这个文件。

以上就是本文的全部内容，如有不足请多指教，共同进步。

转载请注明出处，@via 小风风吖-安卓项目使用GItLib CI/CD实现持续集成 蟹蟹。