持续集成（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平台舒畅...
未完待续。