持续集成和持续部署

概念

持续集成（CONTINUOUS INTEGRATION）

持续集成（ContinousIntergration，CI）是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的编译、发布、自动化回归测试来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。持续集成是为了持续交付。 没有单元测试的持续集成基本无意义。

在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。

持续交付（CONTINUOUS DELIVERY）

持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。
通过持续交付，您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。
但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。

持续部署（CONTINUOUS DEPLOYMENT）

如果我们想更加深入一步的话，就是持续部署了。通过这个方式，任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预（没有一键部署按钮），只有当一个修改在工作流中构建失败才能阻止它部署到产品线。
持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。
持续部署（ContinousDelivery，CD）在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境中。比如，我们完成单元测试后，可以把代码部署到测试环境中，交付给质量团队或者用户，以供评审。如果评审通过， 代码就进入生产阶段。
常规的测试过程：开发送测一个版本——>测试人员从配置库下载版本——>编译版本——>部署到测试环境——>进行冒烟测试——>进行功能测试。 而这些过程完全可以由CI/CD来替代。

DevOps

DevOps是一个完整的面向IT运维的工作流，以IT自动化以及CI、CD为基础，来优化程序开发、测试、系统运维等所有环节。
DevOps实际是一种文化上的变迁，代表了开发、运维、测试等环节之间的协作，因此DevOps工具是非常多种多样的，甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别，并可体现出软 件开发和交付过程的不同阶段：
①编码：代码开发和审阅，版本控制工具、代码合并工具
②构建：持续集成工具、构建状态统计工具
③测试：通过测试和结果确定绩效的工具
④打包：成品仓库、应用程序部署前暂存
⑤发布：变更管理、发布审批、发布自动化
⑥配置：基础架构配置和部署，基础架构即代码工具
⑦监视：应用程序性能监视、最终用户体验

图片

image.png

image.png