Android项目持续集成实践之Gitlab CI

简介

持续集成(Continuous integration)是一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误。

入门

下面我们来简单介绍,如果通过Gitlab CI来对Android项目持续集成。

一言不合,先甩给你一个项目链接:
https://gitlab.com/snowdream/Citest

项目很简单,就是一个默认创建的Android项目,然后上传至Gitlab。

如果给项目添加持续集成功能呢?
按照文档的说法,你需要给项目添加一个名称为.gitlab-ci.yml的配置文件。

.gitlab-ci.yml文件怎么写??此处省略108个字。
通读下面两篇文章,大概就清楚了。
http://doc.gitlab.com/ce/ci/quick_start/README.html
http://doc.gitlab.com/ce/ci/yaml/README.html

当然,也许你读完了,还是感觉蒙了。那你还需要参考下别人怎么实践的。
1. http://doc.gitlab.com/ce/ci/quick_start/README.html
1. http://doc.gitlab.com/ce/ci/yaml/README.html
1. http://www.greysonparrelli.com/setting-up-android-builds-in-gitlab-ci/
1. https://github.com/asura-app/android/blob/master/.gitlab-ci.yml
1. https://github.com/lfuelling/android-sdk-docker
1. https://hub.docker.com/r/jangrewe/gitlab-ci-android/
1. http://blog.goddchen.de/2016/04/configuration-for-gitlab-ci-android-projects/
1. http://stackoverflow.com/questions/35916233/gitlab-com-ci-shared-runner-for-android-projects

实践

下面是重点:
基本流程是:
1. Gitlab Ci通过Docker来拉取包括openjdk-8-jdk的容器
1. 下载Android SDK
1. 通过Gradle Wrapper运行编译工程

下面是主菜:
适用于Android项目的 .gitlab-ci.yml 文件
当然,在实际过程中,你可以需要做一些调整,比如android sdk 中的版本号等。

image: java:openjdk-8-jdk

before_script:
  - apt-get --quiet update --yes
  - apt-get --quiet install --yes wget tar unzip lib32stdc++6 lib32z1
  - wget --quiet --output-document=android-sdk.tgz https://dl.google.com/android/android-sdk_r24.4.1-linux.tgz
  - tar --extract --gzip --file=android-sdk.tgz
  - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter android-23
  - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter platform-tools
  - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter build-tools-23.0.3
  - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-android-m2repository
  - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-google_play_services
  - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-m2repository
  - export ANDROID_HOME=$PWD/android-sdk-linux
  - chmod u+x ./gradlew

build:
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
    - app/build/outputs/

好了。将.gitlab-ci.yml 添加到你的Android项目中,然后上传至Gitlab系列的Git服务器,就开始持续集成了。

详细的构建过程日志太长,我就不贴了。链接如下:
https://gitlab.com/snowdream/Citest/builds/2140420

总结

与Travis Ci相比,Gitlab CI更灵活,可定制性高,但也意味着用起来并不是那么容易。
Travis Ci 更倾向于提供一个开箱即用的 CI服务。
而 Gitlab CI 更倾向于提供一个定制化的CI服务,比如支持Docker。
以上只是对于通过Gitlab CI对Android项目进行持续集成的简单实践。
如果感兴趣,大家可以思考下下面的问题:
1. 怎么通过Gitlab CI进行持续发布?
1. 怎么在Gitlab CI 加密字符串和文件,比如keystore文件?
1. 怎么在Gitlab CI中进行交互性操作,比如输入密码?
1. 怎么在过Gitlab CI中使用缓存?

时间: 2024-12-11 00:20:12

Android项目持续集成实践之Gitlab CI的相关文章

Android项目持续集成实践之Gitlab CI(Docker版本)

接上一篇 Android项目持续集成实践之Gitlab CI. 在我看来,.gitlab-ci.yml 配置还是有些复杂,写的脚本还是有点多,有没有办法更精简一点呢? 有,那就是Android环境Docker化.(注:对Docker感兴趣的同学,请参考这本书<Docker -- 从入门到实践>). 我在这本书的指导下封装了一个包含Android开发环境的Docker镜像. 1. https://github.com/snowdream/docker-android 1. https://hub

Jenkins与Docker的持续集成实践

本文讲的是Jenkins与Docker的持续集成实践[编者的话]持续集成(CI/CD)是一种软件开发实践.用于帮助团队成员频繁.快速的集成,测试他们的工作成果,以尽快发现集成错误. 更频繁.更早的集成意味着更早的发现问题.通过持续集成,及时发现和解决代码故障,提高代码质量,减少故障处理成本等等. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的

【狂云歌之unity_vr】unity项目持续集成dailybuild以及多平台打包管理

[狂云歌之unity_vr]unity项目持续集成dailybuild以及多平台打包管理 前言  持续集成的意义就不多说了.unity通常打包一般就直接build&run,但是在实际项目中,往往直接在服务器build包,所以命令行打包必不可少,这里一方面分享unity打包做持续集成,一方面分享使用unity管理多平台打包,例如一个vrapp需要支持gear版本,支持小米版本,支持cardboard版本等等~懂的人就知道这里具有一定的管理维护成本.  我们做vr相关的app,需要支持gear.ca

Xamarin.Android VSTS 持续集成

这些天做了一个基于 VSTS 的 Xamarin.Android的持续集成,这里分享下 Build Agent 环境需求 DotNetFramework         msbuild         visualstudio         AndroidSDK         JDK Xamarin.Android Build的部分分为以下步骤: 1. 还原NuGet包 a. 这步之所以存在,原因为我使用了Xamarin.Android进行编译,而没有直接对解决方案使用MSBUILD进行编译

IOS6.1单元测试持续集成实践

最近项目测试需要,调研并实践了下IOS下单元测试工具和框架.目前比较流行的工具有xcode自带的OCUnit.GHUnit等,我选择的是GHUnit,因为相比OCUnit,GHUnit具有如下优势: 1.开源框架 2.支持重复测试.单一测试.集成测试. 3.断言方法丰富 4.支持持续集成 5.测试类型多样(UI和Command Line) 官方地址如下:http://gabriel.github.io/gh-unit/ GitHub下载地址:https://github.com/gabriel/

云计算基础设施持续集成实践

[演讲PDF]: https://yq.aliyun.com/attachment/download/?id=1837 [演讲视频]: https://yq.aliyun.com/edu/lesson/551 研发和传统基础设施交互方式 通常情况下,在开发过程中需要和基础设施打交道,需要在项目中申请开发.测试以及预发生产环境.在IDC时代,我们需要向IT部门申请这些资源,其批准后,我们才能获得这些资源.如果这些资源恰巧不足,我们只能等待购买新的资源或者更换其他资源. 当拿到这些资源之后,需要对开

Jenkins 持续集成实践(以网易蜂巢为例)-1 Master 节点的创建

使用场景 当 Github 发生 push 操作时,能够触发测试环境的持续集成. 步骤 搭建 master 节点 蜂巢在官方 jenkins 镜像的基础上 预先安装了 jenkins 的插件 预置了用户 (jenkins/jenkins) jenkins节点分为 master 节点 slave 节点 Master/Slave 相当于 Server/Agent 的概念 Master 节点提供 web 接口来让用户管理 job 和 slave job 可以运行在 master 本机也可以被分配到 s

持续集成实践小结[1] —UI自动化

背景介绍 按照组织上的安排,咱游击到了S产品(一个快速成长中的Web产品)开搞持续集成. 考虑到S产品核心业务单一明确,前端功能简单,业务逻辑主要在后端的特点,制定了持续集成的实施策略: UI自动化为辅,用例少一点,精一点,降低维护成本,用例设计以冒烟和页面跳转,走通业务流程为主,目的是保障一个高可测性的测试环境: 单元测试重点跟进,自顶向下逐步覆盖各层接口,多覆盖各种分支路径,与UI自动化形成互补. 这里有个小插曲,我和S产品的测试负责人关于UI自动化用例的粒度和覆盖度有一些歧义,测试负责人坚

Android热更新开源项目Tinker集成实践总结

前言 最近项目集成了Tinker,开始认为集成会比较简单,但是在实际操作的过程中还是遇到了一些问题,本文就会介绍在集成过程大家基本会遇到的主要问题. 考虑一:后台的选取 目前后台功能可以通过三种方式实现: 1.自己搭建后台布丁下发系统 2.第三方提供的服务,目前如原微信simsun大神的个人tinkerpatch平台,目前出于内测阶段,暂时免费.后期应该会按下发量对app进行收费. 3.腾讯Bugly提供的服务,提供了热更新的下发后台,集成到了bugly的升级sdk中.免费. 根据公司的精神,我