持续集成（Continuous integration，简称 CI）是软件开发工程化的关键流程之一。最近跟朋友做个练手的项目，用 Jenkins 进行持续集成和部署，相关的东西在这里进行一些记录。刚接触不多，一些东西还没有完全理清楚，埋坑待填。
CI 的概念
CI 这个概念其实是比较模糊的。这里的“集成”，最早似乎是指代码的集成。阮一峰 - 持续集成是什么？对相关概念有所阐述。具体而言，就是对提交到分支的代码进行较高频率的构建、测试，通过后就“集成”到主干。这个频率通常为一日多次。这篇文章提到的工作流在目前看来是比较罕见的，里面解释的持续集成跟我们现在常说的持续集成也有不小区别。
而现在说起持续集成，往往是指代码提交后，自动触发自动化测试与构建的过程。这时对“集成”的解释大体有两种说法，一种是说，把测试、构建之类的步骤自动化地集成在一起；另一种说，通过测试、构建来判断代码集成得是否成功。
总体而言，CI 在现在的运用中，是在代码提交后触发的检查步骤，而不是代码提交前的前置步骤。代码提交这一行为，往往根据团队的工作流进行具体定制，不会跟 CI 强绑定。
浏览网上资料的时候要注意，很多时候虽然大家说的都是持续集成这个词，但由于随时间的演化，其内涵可能有很大的不同。
CI 的工具
CI 的工具有很多，大体上分为两大类。一种是第三方平台上的，比如你用 github，相关的 CI 平台就有 Travis CI，Circle CI 等。进行相关配置后，代码提交到 github 就能自动触发，不需要自己部署服务器，当然，这些 CI 服务通常是收费的。如果是开源项目会有一定的免费资源。一种是自己部署的，比如 Jenkins。这种其实不复杂，规定一个触发方式，是定时触发还是通过 github 的钩子去触发；然后自己写个脚本做测试、构建。完了之后想要部署的话也是自己写脚本来搞。Jenkins 主要是对项目、版本、每次构建做下管理，提供 UI 让我们进行一些配置。
这里我只用过 Jenkins，emmm，吐槽一下，上古界面，看起来就没有商用 CI 平台舒畅 …
未完待续。