持续集成与持续部署（一）——核心概念之持续集成、持续交付、持续部署

最新推荐文章于 2024-09-24 08:15:00 发布

viceen

最新推荐文章于 2024-09-24 08:15:00 发布

阅读量2.3k

点赞数 3

分类专栏：架构和运维文章标签： javascript 自动化前端

本文链接：https://blog.csdn.net/weixin_44867717/article/details/123303389

版权

架构和运维专栏收录该内容

78 篇文章 16 订阅

订阅专栏

持续集成与持续部署（一）——核心概念之持续集成、持续交付、持续部署

5-4 持续集成与持续部署

课程介绍

那些大厂们，天天DevOps、持续集成的？到底在讲些什么？这堂课来给你揭开持续集成与持续部署的面纱！！没有什么难的，盘它！

传统的开发过程中的坑：

BUG总是在最后才发现
越到项目后期，加班越严重
交付无法保障
变更频繁导致效率低下
无效的等待多，用户满足度低

在这里插入图片描述

你有没有想过/用过？当你哪一天…

不用为开发/测试环境不一致而苦恼
不用麻烦运维人员帮忙调试环境
不用手动进行测试，模拟环境中进行自测
不用手动发布、部署，自动化实现发布部署
不用管开发/测试环境，只用专注代码的开发？

持续集成解决了什么问题？

提高软件质量
效率迭代
便捷部署
快速交付、便于管理

课程的主要内容：

什么是CI/CD
介绍CI/CD流程
前端项目：结合CI/CD流程，实现快速迭代
Docker的使用，Jenkins+gitlab+nodejs自动化项目
持续集成工具介绍：Jenkins、Travis CI、Circle CI

环境准备：

Linux服务器(Centos 7.6/Ubuntu 16.04LTS)
VSCode+插件 Dockerfile
注册github账号

持续集成

核心概念

集成，就是一些孤立的事物或元素通过某种方式集中在一起，产生联系，从而构成一个有机整体的过程。知识经济的社会，集成已经成了很重要的一个名词。各行各业基本都会用到集成。比如汽车行业，那么复杂的一台跑车愣是通过一大堆零件组装起来。对于这些传统行业，它们在研发成功以后，可以通过流水线的方法批量生产进行集成。而在软件行业中，集成并不是一个简单的“搬箱子”的过程。因为软件工业是一个知识生产活动，其内在逻辑非常复杂，需求又很难一次性确定，完成的产品与最初的设计往往相差很远。敏捷宣言中就有一条是说响应变化重于遵循计划。而且由于软件行业的迅猛发展，软件变的越来越复杂，单靠个人是根本无法完成。大型软件为了重用及解耦，往往还需要分成好几个模块，这样集成就成了软件开发中不可或缺的一部分。

持续，不言而喻，就是指长期的对项目代码进行集成。

持续集成

持续集成（英文：Continuous Integration，简称CI）

在软件工程中，持续集成是指将所有开发者工作副本每天多次合并到主干的做法。

Grady Booch 在1991年的 Booch method 中首次命名并提出了 CI 的概念，尽管在当时他并不主张每天多次集成。而 XP（Extreme programming，极限编程）采用了 CI 的概念，并提倡每天不止一次集成。

在《持续集成》一书中，对持续集成的定义如下：持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他们的工作成果，一般每人每天至少集成一次,也可以多次。每次集成会经过自动构建(包括自动测试)的检验，以尽快发现集成错误。自从在团队中引入这样的实践之后，Martin Fowler发现这种方法可以显著减少集成引起的问题，并可以加快团队合作软件开发的速度。

在这里插入图片描述

持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。

对于一天需要集成多少次数，并没有一个明确的定义。一般就是按照自己项目的实际需要来设置一定的频率，少则可能几次，多则可能达几十次。可以设置按照代码的变更来触发集成，或者设置一个固定时间周期来集成，也可以手工点击集成的按钮来“一键集成”。

持续交付

持续交付（英文：Continuous Delivery，简称CD）

完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在这里插入图片描述

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。

比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。

持续部署

持续部署（英文：Continuous Deployment，简称CD）

对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。

在这里插入图片描述

实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。

持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。
方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。

持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。