正文
在日常的开发过程中，程序员在本地提交代码，持续集成流水线要求先做一次本地集成，在本地进行验证后提交到源代码管理仓库中，之后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后，会及时通过钉钉或邮件通知团队（测试/研发/boss/产品经理）集成状态，产品经理或项目经理收到通知后会在测试环境做验收测试，这是一个比较完美的反馈环。
假如测试通过验收完毕后，持续集成系统会自动触发部署到类生产环节或测试环境，或由专人手动部署到生产环境。
为什么要做本地集成
首先，代码在远程进行管理，每个人都会提交代码，远程的代码仓库会产生变化，所以在本地集成的时候要求进行代码合并，以免出现分支冲突和代码冲突。其次，不要依赖于持续集成系统给你结果，可能需要 30 分钟的时间，不要让开发人员等待，一定要先做本地集成。
如何做版本提交
再说一个提交的问题，我们尽量保证每一次提交都是一个完整的提交，也就是原子提交。
当代码变动你想创建提交时，这个提交应该尽可能的小量，并且包含一个不可分割的特性（feature）、修复（fix）或优化（improved）。
拿每个产品开发都会遇到的 login 功能开发举例，当填完的用户名和密码传到数据库，做完验证后给用户返回一个结果。那什么是一个原子提交？比如，提交验证一个用户名，这是一个完整的 feature ；验证密码是否符合格式（6位/8位），这也是一个完整的 feature ；当我验证完用户名和密码后再传到数据库之后，查询正确与否，这也是一个完整的 feature ；保证每次提交是一个完整的 feature 或修复了一个 bug，不要代码写成半截。
持续集成系统
这里讲的是狭义的持续集成系统，通常的 CI 系统收到提交之后会触发构建，构建会有信息返回比如 commit id 、commit 信息、代码变更等，收到代码提交后会触发自动构建，接着安装依赖进行编译，并触发质量保证流程，也就是说自动化测试集。
自动化测试集包括代码静态检查－单元测试－集成测试－验收测试－性能测试，也会有压力测试、回归测试、monkey test 等等一系列的测试。
接下来，具体讲一下我们团队的持续集成技术实践。
目前在使用的敏捷环境
