简评：持续集成（Continuous Integration）一直被认为是敏捷开发的重要实践之一，也是提升软件质量的重要手段。特别在团队协作中，为项目添加持续集成还是非常有必要的。
Continuous Integration - 持续集成，持续集成是一种软件开发实践，通过自动化的构建（包括编译、发布和自动化测试）来验证，从而帮助尽快发现集成错误。
这里我们以 github 和 bitrise.io 为例，因为比较简单，专注于移动应用，功能也比较丰富。
首先，创建 bitrise.io 的账号并添加你的 github 项目，主要有两件事要做：
- 添加 webhook
- 分支保护
Webhook 能当你的仓库发生某些事件时通知外部服务（push, pull-request 等等）。对于 bitrise.io 来说，当执行了 pull 或 pull-request 时会自动进行 build。
当你将 github 账号和 bitrise.io 的账号进行了绑定，会自动添加 webhook。
当然，也可以手动添加，首先在 Code 页面中复制 webhook 地址：
之后，在 github 的项目设置页面中选择 Webhooks，把复制好的 url 粘贴进 Payload URL 栏，再选择 Send me everything，最后点击 Add webhook 按钮：
分支保护是禁止强推，防止分支被删除并在分支合并前进行状态检查。
为了开启分支保护，在 github 项目设置页面中选择 Branches，再勾选想要保护的分支：
Status check 能保证在合并 pull request 之前先执行 bitrise.io build，下面是几个示例：
Build
bitrise.io 的 build 有下列的生命周期：
- Build 触发
- Workflow 执行
- App 准备就绪
**Trigger **决定了「什么时候」和「build 什么」。打开 bitrise.io 项目页面，点击 Workflow 标签并选择 Triggers 就可以设置 Trigger 了。
下面就是当从 dev 分支给 prod 分支发送 pull 请求时执行 workflow 的 trigger。
**Workflow **定义了 build 的步骤，可以按照你的需要来进行自定义。同样，在bitrise.io 项目页面中，点击 Workflow 标签。在这里你就能创建或编辑 workflow。
下面，就以一个 workflow 为例：
- Clone 项目仓库
- 执行 gradle 任务 assembleProdRelease 生成 .apk
- 执行 gradle 任务 lintProdRelease 检查是否有 lint issue
- 执行 gradle 任务 pmd 检查是否有 pmd issue
- 执行 gradle 任务 findbugs 检查是否有 findbugs issue
- 将 apk 文件部署到 bitrise.io 进行分发
当 build 完成后，将能够看到有关 build 的详细信息，比如用时、状态、日志等等。
最后，你会得到一个公开的 apk 下载地址：
如果哪里出了问题，你可以检查 build 日志：
Bitirse 支持的 Integration：
原文：Configuring Android Project — Continuous Integration**
欢迎关注知乎专栏「极光日报」，每天为 Makers 导读三篇优质英文文章。
相关阅读：
