从持续构建到持续集成
遗留系统的构建方式
在遗留系统中，一次上线前构建过程可能是这样的：一位打包专员，在本地或远程的机器上拉取代码，完成集成、打包和测试的工作，并准备手动部署。这时，即使再紧急的代码提交都会被拒绝，因为一个干净的打包环境来之不易，新引入的代码会导致所有的流程重来一遍。
Kent Beck 早在上世纪 90 年代就提出了持续集成的概念，即集成的频率越高越好，极限情况下就是持续地每时每刻都在集成。这就是极限编程的理念：越是痛苦的事情，就越要频繁地去做，这样每次做的时候就没有那么痛苦。
持续构建
持续构建是指，每次代码提交都会触发一次构建工作，并执行一些相关任务。这个过程由持续集成工具自动化完成，大致过程如下：
1. 开发人员将代码提交（PUSH）到远程代码仓库；
2. 持续集成服务器按一定时间间隔（比如 1 分钟）轮询代码仓库，以便及时发现代码变更；
3. 如果发现了代码变更，持续集成服务器就将代码拉取（PULL）到自己本地；
4. 持续集成服务器按照指定的构建脚本执行各项任务，包括编译、单元测试、代码扫描、安全扫描、打包等；
5. 任务执行完毕后，会把结果（成功或失败）反馈给开发团队。
有了持续构建，就能解决遗留系统最头疼的问题之一：不知道从哪去找可以部署到各个环境的软件包。打包部署不再依赖于打包专员的手工操作，大大缩短和简化了部署流程。
在遗留系统中引入持续构建
建议选用 Atlassian 公司的三件套：BitBucket、Jira 和 Confluence。可以将代码管理、需求管理和知识管理打通，补齐遗留系统中缺失的这些内容。
遗留系统要做到单次构建（如每日构建）还是相对容易的，但要想做到“持续”构建，开发人员就必须改变之前的一些工作习惯。就拿提交代码来说，很多开发人员会等到所有的代码都编写完成，才进行一次提交。这样，代码冲突的风险非常高，很可能出现代码写了两天，合并就用了半天的尴尬情况。如果每个人都这样，就无法做到每天构建多次的目标。
要避免这种局面，开发人员就要对自己编写的代码做出良好的规划，分解出若干小的任务，每个任务都能在很短的时间内完成，而且任务最好是按照一个功能的端到端的场景来划分，而不要按技术层级去划分。
做好任务分解，做到小步提交。小步提交不是指每次commit尽量少的代码，如果提交的内容很少，但却破坏了编译和测试，这样的提交也是不合格的。
真正的小步提交是指，每个commit都完成了一个端到端的功能点，因此都是可以PUSH到代码仓库的。可以针对这个commit进行验证，测试甚至是部署。
七步提交法
1.PULL 最新代码，确保在最新的代码基础上开始开发；
2. 本地编写代码；
3. 本地构建：本地执行编译和单元测试等，以确保新编写的代码是可以工作的；
4.PULL 最新代码：需要先检查 CI 状态，如果是绿色则可以 PULL；
5. 本地构建：再次执行编译和单元测试，以确保新编写的代码和最新代码可以成功集成；
6.PUSH 代码：将本地修改 PUSH 到远端服务器；
7. 流水线构建：触发 CI 流水线进行构建，并监控流水线状态，直到通过。
持续集成
持续集成包含持续构建的所有步骤，并且在它后面还增加了部署到某个环境的流程，比如部署到测试环境，并且进行冒烟测试、接口测试等。同时，在这个阶段，你还可以优化一下流水线，进一步提升效率。
持续集成流水线的重要作用之一就是快速反馈。对于编译不通过、测试失败、代码风格不符合标准等问题，我们都希望第一时间看到流水线失败，继而根据日志去分析失败原因，快速修复。但遗留系统的代码库往往很庞大，仅仅编译可能就会很长时间，如果再跑测试和代码扫描，我们得到反馈的时间就会大大拉长。
对构建进行分级，把那些执行速度快、反馈质量高的步骤放到一级构建中，将执行速度慢的步骤放到次级构建环节。比如单元测试执行的速度很快，就可以放到较早的构建环节；而集成测试很慢，就可以放到次级构建；对于代码扫描这种更慢的构建，甚至可以使用单独的流水线，在每天晚上执行一遍。只有把不同构建过程按执行速度和反馈效果拆分为不同阶段，整个构建或集成过程才更像是一条真正的流水线。
小结
标签：集成,持续,代码,现代化,DevOps,构建,提交,流水线 From： https://www.cnblogs.com/rickybelment/p/16772116.html