关于webpack:WEB前端线上系统课2022最新已更新至916集day52实时更新中

4次阅读

共计 2559 个字符，预计需要花费 7 分钟才能阅读完成。

手把手教你用 Jenkins 主动部署 SpringBoot
CI/CD 是一种通过在利用开发阶段引入自动化来频繁向客户托付利用的方法。
CI/CD 的核心概念可能总结为三点：

继续集成
继续托付
继续部署

CI/CD 次要针对在集成新代码时所引发的问题（俗称 ” 集成地狱 ”）。
为什么会有集成地狱这个“雅称”呢？大家想想咱们一个我的项目部署的过程，拉取代码 -> 构建 -> 测试 -> 打包 -> 部署，如果咱们常常需要部署我的项目，特地是在微服务期间，服务特地多的情况下，不停的测试打包部署，那估计得有集体一整天顺便做这事了，而这事又是繁琐的重复无意义的。
具体而言，CI/CD 可让继续自动化和继续监控贯穿于利用的整个生命周期（从集成和测试阶段，到托付和部署），这些关联的事务通常被统称为 ”CI/CD 管道 ”，由开发和运维团队以敏捷形式协同反对。
1.1 CI（Continuous Integration）
CI/CD 中的 ”CI” 始终指继续集成，它属于开发人员的自动化流程。胜利的 CI 意味着利用代码的新更改会定期构建、测试并合并到代码仓库中，该解决打算可能解决在一次开发中有太多利用分支，从而导致相互冲突的问题。
1.2 CD（Continuous Delivery/Continuous Deployment）
CI/CD 中的 ”CD” 指的是继续托付和 / 或继续部署，这些相干概念有时会交叉使用。两者都事关管道后续阶段的自动化，但它们有时也会独自使用，用于说明自动化程度。
继续托付（Continuous Delivery）通常是指开发人员对利用的更改会主动进行谬误测试并上传到代码仓库（如 GitHub、GitLab 等），而后由运维团队将其部署到实时生产环境中。这旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，继续托付的目标就是确保尽可能减少部署新代码时所需的工作量。
继续部署（Continuous Deployment）指的是主动将开发人员的更改从代码仓库公布到生产环境，以供客户使用。通过一套全自动化的流程，来解决手动测试、编译、打包等操作。继续部署以继续托付的劣势为根基，实现了管道后续阶段的自动化。

什么是 Jenkins
后面说的 CI/CD 算是一种思维，思维要落地，就需要对应的工具。
Jenkins 是一款开源的 CI/CD 软件，可能算是 CI/CD 软件指导者，它提供了超过 1000 个插件来反对构建、部署、自动化，基本上能够满足任何我的项目的需要。
整体来说，Jenkins 有如下六大个性：

继续集成和继续托付

作为一个可扩大的自动化服务器，Jenkins 可能用作简略的 CI 服务器，或者变成任何我的项目的继续托付核心。

繁难安装

Jenkins 是一个基于 Java 的独立程序，可能立即运行，蕴含 Windows、Mac OS X 和其余类 Unix 操作系统。

配置简略

Jenkins 可能通过其网页界面轻松设置和配置，其中包含即时谬误检查和内置帮助。

插件

通过更新核心中的 1000 多个插件，Jenkins 集成了继续集成和继续托付工具链中几乎所有的工具。

扩大

Jenkins 可能通过其插件架构进行扩大，从而为 Jenkins 可能做的事提供几乎有限的可能性。

分布式

Jenkins 可能轻松地在多台机器上调配工作，帮助更疾速地跨多个平台推动构建、测试和部署。
其实 Jenkins 有很多好玩的用法，明天我还是想先通过一个简略的案例，先来和大家捋一捋如何使用 Jenkins 来实现一个 Spring Boot 我的项目的主动公布部署，这样大家对 Jenkins 现有一个直观的认知，各种其余使用细节松哥在当前的文章中再来和大家细聊。

3.2 筹备代码
提前筹备好测试代码，并上传到代码仓库中。为了更加真切一些，小伙伴们可能将这个代码仓库设置为公有的，这样将来可能测验 Jenkins 中的配置是否正确。
考虑到 GitHub 网络有时候不稳固，我这里使用了 Gitee，一个很简略的 Spring Boot 工程，里边有一个 hello 接口，仅此而已。

3.3 筹备服务器
实践上，咱们需要一台服务器用来跑 Jenkins，还需要一台服务器作为我的利用服务器，然而我手头没有多余的服务器，所以我就将 Jenkins 和我的 Spring Boot 我的项目部署到一台服务器上，在接下来的文章中我会和大家说明每个配置是针对 Jenkins 的还是针对 Spring Boot 的。
另外，有的小伙伴可能是在虚拟机上做试验，因为将来咱们的代码提交到 Gitee 之后，Gitee 会通过一个 POST 请求将这个事件告知 Jenkins，进而触发 Jenkins 的构建操作。所以这就申请 Gitee 能够拜访到你的 Jenkins 服务器，所以如果你的 Jenkins 刚好搭建在服务器上，这事就很容易了，但如果是搭建在虚拟机里，就得通过花生壳之类的内网穿透工具来辅助你的工作了，比较麻烦，而且花生壳网速也慢。
不过小伙伴们不必担心，如果你在虚构上搭建的 Jenkins，并且不违心折腾花生壳，那么也可能通过手动构建 / 定时构建的形式去实现我的项目构建的。

搭建 Jenkins
为了省事，我决定用 Docker 搭建 Jenkins，一行命令搞定。
为了操作便利，咱们将 Jenkins 的工作目录映射到我的宿主机中来，因此首先在宿主机中筹备一个数据目录（不是必须）：

创建 jenkins 目录

mkdir /data/jenkins_home/

修改目录的所有者，以便于 Jenkins 容器能够操作该目录

chown -R 1000:1000 /data/jenkins_home/
复制代码
接下来创建并启动 Jenkins 容器，同时挂载数据卷：
docker run -d –name jenkins -p 8088:8080 -p 50000:50000 -v /data/jenkins_home:/var/jenkins_home jenkins/jenkins
复制代码
因为 Jenkins 在运行的时候需要用到 maven，所以有的人会抉择将 maven 目录也作为挂载点，然而我感觉没有必要，特地是对于初学者而言，这块很容易出错，不如将 maven 将来间接拷贝到 Jenkins 容器中，这样反而省事一些。
执行如上命令，安装胜利之后，阅读器输出 http://localhost:8088 就可能拜访了。