从IDEA到生产环境：一文搞懂Docker、Gogs、Jenkins与企业CI/CD完整流程（天机学堂实战）
企业为什么要用 Docker、Gogs、Jenkins？
第一章：企业开发模式——为什么企业需要统一开发环境
本文基于黑马《天机学堂》的项目实践，但并不仅仅介绍 Docker、Gogs、Jenkins 的安装，而是站在企业开发的角度，帮助大家理解它们为什么会出现，以及它们之间是如何协同工作的。
前言
很多人在学习微服务的时候，都会遇到 Docker、Git、Jenkins、Nacos、Redis、MySQL、RabbitMQ……
课程里通常会教大家把这些软件安装好，然后运行项目。
但是很多人学完之后，仍然有一个疑问：
为什么企业一定要这样开发？
为什么不能像以前学习 Java Web 一样：
- IDEA 打开项目
- 点击 Run
- 浏览器访问
为什么还要学习 Docker？
为什么要搭建 Gogs？
为什么还要配置 Jenkins？
事实上，这些工具都不是孤立存在的，它们共同组成了现代企业研发流程的一部分。
而理解它们最好的方式，不是先学习命令，而是先理解企业开发模式。
一、个人项目与企业项目最大的区别
刚开始学习 Java 时，我们写的项目通常都很简单。
例如一个 Spring Boot 项目：
Spring Boot
│
MySQL
启动 MySQL。
运行 Spring Boot。
项目即可访问。
整个开发流程非常简单。
但是，当进入企业以后，项目规模会发生巨大的变化。
例如一个典型的 Spring Cloud 微服务项目：
Gateway（网关）
User Service（用户服务）
Course Service（课程服务）
Trade Service（交易服务）
Search Service（搜索服务）
Redis
MySQL
RabbitMQ
Nacos
MinIO
Elasticsearch
XXL-JOB
此时，一个完整项目可能包含十几个甚至几十个服务。
每个服务都有自己的数据库连接、配置文件和运行环境。
整个系统已经不是"启动一个项目"那么简单了。
二、企业开发为什么容易出现环境问题？
假设团队里有四位开发人员。
A：
- Windows 11
- JDK 21
- MySQL 8.0
- Redis 7
B：
- Windows 10
- JDK 17
- MySQL 5.7
- Redis 6
C：
- Ubuntu
- Docker
D：
- macOS
如果大家都按照自己的方式安装软件，很快就会出现各种问题。
例如：
开发 A：
我这里运行正常。
开发 B：
Redis 怎么连不上？
开发 C：
MySQL SQL 语法报错。
开发 D：
为什么 Docker 能运行，你们不能？
最后，经常会出现一句程序员经典名言：
"我这里没问题。
问题真的出在代码吗？
很多时候并不是。
真正的问题，是开发环境已经不一致了。
三、企业首先解决的不是代码，而是环境
很多初学者认为：
Docker 是为了部署。
其实，这只是它的一部分作用。
企业真正首先解决的问题，是：
如何保证所有开发人员拥有完全一致的运行环境。
例如：
所有开发人员统一使用：
- JDK 17
- MySQL 8
- Redis 7
- RabbitMQ 3.12
- Nacos 2.x
这样：
开发环境 == 测试环境 == 生产环境
才能保证：
在开发环境运行成功的程序，到测试环境依然能够运行。
这就是现代企业为什么越来越依赖容器技术的原因。
四、为什么企业要划分多个环境？
很多同学第一次进入公司都会发现：
除了自己的电脑，公司还有很多服务器。
例如：
开发环境（Development）
↓
测试环境（Testing）
↓
预发布环境（Staging）
↓
生产环境（Production）
为什么不能只有一台服务器？
原因很简单。
不同阶段承担着不同的职责。
1、开发环境（Development）
开发环境就是程序员日常工作的地方。
主要用于：
- 编写代码
- 调试功能
- 修改 Bug
- 联调接口
这里的数据一般可以随意修改。
出现问题也不会影响真实用户。
2、测试环境（Testing）
测试环境主要提供给测试人员。
测试人员会：
- 功能测试
- 接口测试
- 回归测试
- 压力测试
确保每个版本没有明显问题。
3、预发布环境（Staging）
很多人容易忽略预发布环境。
它最大的作用就是：
模拟真实生产环境。
例如：
- 数据库配置一致
- Redis 配置一致
- Linux 系统一致
- Docker 镜像一致
如果预发布都运行正常，那么上线风险就会大幅降低。
4、生产环境（Production）
生产环境就是最终提供给用户访问的服务器。
这一环境具有几个特点：
- 数据真实
- 用户真实
- 不能随意修改
- 稳定性要求最高
任何一次错误部署，都可能影响大量用户。
因此，企业不会允许开发人员直接把代码复制到生产服务器运行。
必须经过完整的审核和自动化流程。
五、为什么需要自动化？
假设一个项目每天提交代码 30 次。
如果每次都需要人工完成下面这些操作：
git pull
↓
mvn clean package
↓
复制 Jar
↓
停止服务
↓
启动服务
↓
通知测试
一天下来，将会浪费大量时间。
而且：
每一步都可能出现人为失误。
例如：
忘记更新代码。
忘记打包。
启动了错误版本。
因此，企业希望：
把重复工作交给机器完成。
于是：
自动化构建（CI）和自动化部署（CD）开始出现。
后面的 Jenkins，就是完成这些工作的核心工具。
六、现代企业开发模式
现代企业的软件开发流程，大致如下：
需求分析
↓
开发编码
↓
Git 提交代码
↓
自动构建
↓
自动测试
↓
部署测试环境
↓
测试验收
↓
发布生产
可以发现，程序员真正需要关心的只有：
- 编写代码
- 提交代码
剩下的大部分重复工作，都交给自动化平台完成。
这也是现代 DevOps 的核心思想之一：
让开发更加专注于业务，而不是重复劳动。
七、本章小结
通过这一章，我们可以得出几个重要结论：
✅ 企业项目比个人项目复杂得多，涉及多个微服务和基础组件。
✅ 环境不一致，是企业开发中最常见的问题之一。
✅ Docker 的首要价值并不是部署，而是统一运行环境。
✅ 企业通常会划分开发、测试、预发布和生产环境，以保证系统稳定性。
✅ 自动化构建和部署，可以减少人为操作，提高研发效率。
理解了这些背景之后，我们就可以进一步思考：
企业究竟是如何做到环境统一的？
下一章，我们将正式进入 Docker，看看它为什么能够成为现代微服务开发中最重要的基础设施之一。
💡 我的理解
很多初学者认为：
Docker 是部署工具。
实际上，更准确的说法应该是：
Docker 首先解决的是环境一致性，其次才是部署效率。
只有当开发、测试、生产运行的是同一个镜像时，“开发环境正常、线上环境报错” 这类问题才能真正减少。
这也是后续学习 Gogs、Jenkins 和 CI/CD 的基础。
第二章：Docker、Gogs、Jenkins 原理
——理解三大核心工具在企业开发中的职责
在上一章中，我们了解了企业为什么需要统一开发环境，以及为什么要划分开发、测试、预发布和生产环境。
那么，企业究竟是如何实现这一切的？
答案就是今天的三个主角：Docker、Gogs、Jenkins。
它们看似毫无关系，实际上却构成了现代企业研发流程中最基础的一条链路。
一、先不要急着学习命令
很多初学者学习 Docker 时，第一件事情就是：
docker pull
docker run
docker ps
docker exec
学习 Jenkins 时：
- 新建任务
- 配置 Maven
- 配置 Git
学习 Gogs 时：
- 创建仓库
- Push 代码
虽然这些操作都会了，但是仍然不知道：
为什么企业一定要这样做？
其实，这三个工具分别解决的是三个完全不同的问题。
| 工具 | 解决的问题 |
|---|---|
| Docker | 如何保证程序运行环境一致 |
| Gogs | 如何管理团队代码 |
| Jenkins | 如何自动完成重复工作 |
因此，我们可以把它们理解为企业开发流程中的三个不同角色。
二、Docker：统一运行环境
1、Docker 出现之前
假设现在需要部署一个 Spring Boot 项目。
运行它，需要：
- JDK
- Maven
- MySQL
- Redis
- RabbitMQ
- Linux
- 环境变量
- 配置文件
只要其中任何一个版本不同，都可能导致项目无法运行。
例如：
开发环境：
JDK17
MySQL8
Redis7
↓
生产环境：
JDK21
MySQL5.7
Redis6
最终结果就是：
开发：
正常运行
↓
生产：
启动失败
这也是为什么很多程序员都会说：
"我这里没问题。
因为：
代码没有问题。
环境有问题。
2、Docker 的核心思想
Docker 提供了一种新的思路：
把程序和运行环境一起打包。
例如：
Spring Boot
+
JDK17
+
配置文件
+
依赖库
=
Docker Image
这里产生了第一个重要概念：
Image（镜像）
镜像可以理解为：
一个已经打包好的程序模板。
里面包含：
- 程序代码
- Java 环境
- 配置
- 启动方式
- 所有依赖
因此：
无论复制到哪台服务器。
运行结果都一致。
3、Container（容器）
镜像只是模板。
真正运行程序的是：
Container（容器）。
关系如下：
Docker Image
↓
docker run
↓
Docker Container
可以理解成：
镜像
≈
类（Class）
容器
≈
对象（Object）
一个镜像：
可以运行多个容器。
例如：
SpringBoot Image
↓
Container1
Container2
Container3
这也是 Docker 可以快速扩容的重要原因。
4、为什么 Docker 特别适合微服务？
微服务意味着：
每个服务都可以：
独立部署。
例如：
Gateway
↓
Image
↓
Container
User Service
↓
Image
↓
Container
Order Service
↓
Image
↓
Container
彼此之间互不影响。
如果订单服务出现问题：
只需要重启订单服务即可。
不会影响其他系统。
这就是容器化部署最大的优势。
5、Docker Compose
当天机学堂启动项目时。
大家会发现：
不仅需要启动项目。
还需要：
- MySQL
- Redis
- RabbitMQ
- Nacos
- MinIO
如果每个容器都：
docker run
将会非常麻烦。
于是：
Docker Compose 出现了。
它允许：
docker-compose.yml
统一描述：
mysql
redis
rabbitmq
nacos
minio
然后：
docker compose up -d
即可一次启动整个开发环境。
这也是课程中为什么会提供 docker-compose.yml 文件的原因。
三、Gogs：企业自己的 GitHub
很多同学第一次看到 Gogs。
都会问：
它是不是 Git？
答案：
不是。
1、Git 是什么？
Git 是：
版本控制工具。
负责：
- 记录代码历史
- 管理分支
- 合并代码
- 回滚版本
例如：
git add
git commit
git push
这些命令。
都是 Git 完成的。
2、为什么还需要 Gogs？
Git 只能管理本地仓库。
如果团队开发。
还需要：
一个远程仓库。
例如：
开发A
↓
Push
↓
服务器
↓
开发B Pull
这个服务器：
就是 Git 仓库。
常见的有：
- GitHub
- GitLab
- Gitea
- Gogs
3、企业为什么不用 GitHub？
很多互联网公司：
代码属于企业资产。
通常不会直接托管到公网。
因此：
会自己搭建 Git 服务。
例如：
公司服务器
↓
Gogs
↓
Git Repository
这样：
既保证安全。
又方便权限管理。
4、Gogs 在整个流程中的作用
很多初学者误认为：
Gogs 用来部署项目。
实际上：
它只负责：
保存代码。
例如：
开发
↓
git push
↓
Gogs
↓
代码保存成功
真正部署项目。
还没有开始。
5、Webhook
这里出现一个重要概念：
Webhook。
当：
git push
完成后。
Gogs 可以自动通知 Jenkins：
有新的代码提交了。
这就是：
Webhook。
它相当于：
Push
↓
发送消息
↓
Jenkins 收到通知
整个过程。
不需要人工点击。
四、Jenkins：企业自动化流水线
很多教程一句话：
Jenkins 是持续集成工具。
其实：
更容易理解的说法应该是：
Jenkins 是自动执行任务的平台。
1、没有 Jenkins 时
程序员每次发布：
需要：
git pull
↓
mvn clean package
↓
复制 Jar
↓
停止服务
↓
启动服务
↓
通知测试
重复几十次。
既浪费时间。
又容易出错。
2、有 Jenkins 后
只需要：
git push
剩下全部自动完成。
例如：
Git Clone
↓
Maven Compile
↓
Unit Test
↓
Package
↓
Docker Build
↓
Docker Run
↓
Deploy
这就是：
流水线（Pipeline）。
3、为什么叫 Pipeline？
因为：
每一步都是上一阶段的输出。
例如：
代码
↓
编译
↓
Jar
↓
Docker Image
↓
Docker Container
↓
测试服务器
整个过程：
像流水线一样。
自动流转。
4、Jenkins 为什么能够部署 Docker？
很多同学容易误解：
Docker 自动部署。
其实：
真正发出命令的是：
Jenkins。
例如：
Jenkins：
执行：
docker build
然后：
执行：
docker run
因此：
Docker：
负责运行。
Jenkins：
负责调度。
职责完全不同。
五、三者之间到底是什么关系？
很多初学者：
学习的时候。
容易认为：
Docker、Gogs、Jenkins
是三个独立的软件。
实际上：
它们更像：
一家公司的三个部门。
例如：
Docker
↓
负责运行程序
Gogs
↓
负责保存代码
Jenkins
↓
负责安排工作
三者协同之后。
企业开发流程就变成：
开发人员
↓
Git Push
↓
Gogs
↓
Webhook
↓
Jenkins
↓
Git Clone
↓
Maven Build
↓
Docker Build
↓
Docker Run
↓
测试服务器
这张图，也是整个 CI/CD 的核心流程。
六、本章小结
经过这一章，我们已经能够理解三个工具各自承担的职责：
| 工具 | 核心职责 | 是否直接运行项目 |
|---|---|---|
| Docker | 提供一致的运行环境 | ✅ 是 |
| Gogs | 管理代码仓库 | ❌ 否 |
| Jenkins | 自动化构建与部署 | ❌（负责调度） |
很多人在学习过程中会觉得三者联系不大，其实它们分别对应企业开发中的三个关键问题：
- Docker 解决“程序在哪都能跑”的问题。
- Gogs 解决“团队如何协同开发”的问题。
- Jenkins 解决“如何自动完成重复工作”的问题。
三者配合后，才能真正实现现代企业常说的 持续集成（CI） 和 持续交付（CD）。
💡 我的理解
很多初学者喜欢把 Docker、Gogs、Jenkins 当成三个独立的软件学习，但在企业中，它们其实是同一条研发流水线上的三个环节。
如果把企业开发比作一家工厂：
- Gogs 就像仓库，负责保存原材料（代码）。
- Jenkins 就像流水线调度中心，负责安排加工流程。
- Docker 就像标准化生产车间，保证每件产品（应用）都在一致的环境中生产和运行。
只有三者协同工作，企业才能真正做到开发、测试、部署一体化。这一点，也是理解后续 CI/CD 流程的关键。
第三章：CI/CD 与企业部署流程
——一次 git push 的背后，到底发生了什么？
学完 Docker、Gogs、Jenkins 后，很多人仍然会有一个疑问：
为什么我只执行了一次
git push，测试服务器上的项目就自动更新了？其实，这就是 CI/CD（持续集成 / 持续交付 / 持续部署） 的价值。
在这一章，我们将以企业真实项目为例，完整梳理一次代码提交后的自动化流程。
一、什么是 CI？
CI（Continuous Integration），中文通常翻译为 持续集成。
很多教材会直接给出定义：
持续集成，就是频繁地将代码集成到主干，并通过自动化流程验证代码质量。
这句话没有错，但对于初学者来说并不容易理解。
我们不妨先看一个没有 CI 的团队。
没有 CI 的开发模式
假设一个团队有四名开发人员。
他们分别负责：
- 用户模块
- 课程模块
- 支付模块
- 搜索模块
大家都在本地开发。
直到周五下午：
开发A：
提交代码
开发B：
提交代码
开发C：
提交代码
开发D：
提交代码
然后：
项目开始打包。
结果：
编译失败
继续修改。
修改完成。
再次打包。
结果：
接口冲突
继续修改。
最后终于能够部署。
整个下午几乎都在解决：
“为什么代码合不到一起？”
这就是传统开发模式的问题。
大家开发的时候都觉得没问题。
真正的问题发生在：
最后集成的时候。
因此：
持续集成（Continuous Integration）提出了一个新的理念：
不要等到最后一起集成，而是每次提交代码都立即进行验证。
二、CI 到底做了什么？
CI 的核心其实只有一句话：
每一次提交，都自动检查代码是否还能正常工作。
例如：
开发人员：
git push
随后：
Jenkins
↓
拉取最新代码
↓
Maven 编译
↓
执行测试
↓
打包 Jar
↓
生成 Docker 镜像
↓
部署到测试环境
整个过程完全自动完成。
如果中间任何一步失败：
例如：
编译失败
测试失败
Docker Build 失败
流水线立即停止。
开发人员马上收到通知。
这样：
问题能够在几分钟内被发现。
而不是几天之后。
三、CI 为什么能够提高开发效率？
很多初学者认为：
CI 的作用就是自动打包。
实际上：
真正的价值在于：
尽早发现问题。
例如：
开发 A：
修改了接口。
开发 B：
依赖了旧接口。
如果：
没有 CI。
可能：
两天之后才发现。
如果：
有 CI。
第一次提交：
立即编译失败。
开发人员当天就能修复。
因此：
CI 并不是为了省几分钟打包时间。
而是为了：
降低多人协作带来的风险。
四、什么是 CD？
很多人容易把 CI 和 CD 混淆。
实际上：
CD 有两种不同的含义。
第一种：Continuous Delivery（持续交付）
持续交付强调：
代码已经具备随时发布的能力。
流程如下：
提交代码
↓
自动编译
↓
自动测试
↓
自动部署到测试环境
↓
人工确认
↓
发布生产环境
这里：
最后一步：
仍然需要人工确认。
很多企业采用的就是这种方式。
因为：
生产环境风险较高。
必须经过审核。
第二种：Continuous Deployment（持续部署）
持续部署则更加自动化。
流程如下：
提交代码
↓
自动编译
↓
自动测试
↓
自动部署测试
↓
自动部署生产
整个过程：
没有人工参与。
只要测试通过。
立即上线。
这种模式：
适合：
- 自动化测试完善
- 发布频率高
- 风险可控
例如：
互联网平台。
五、一次 git push 后，到底发生了什么？
这一部分，是整个 CI/CD 的核心。
假设：
开发人员完成一个功能。
随后执行：
git add .
git commit -m "完成课程查询功能"
git push
看起来：
只有一个 Push。
实际上：
企业服务器已经开始工作。
第一步：Gogs 接收代码
开发人员：
Git Push
↓
Gogs：
收到新的 Commit。
更新远程仓库。
随后：
触发：
Webhook。
第二步：Webhook 通知 Jenkins
Webhook 可以理解成：
“有人提交代码了。”
收到通知后：
Jenkins：
立即启动流水线。
整个过程：
不需要任何人工点击。
第三步：Jenkins 拉取最新代码
Jenkins：
执行：
Git Clone
或者：
Git Pull
确保：
获取最新版本。
第四步：Maven 编译
随后：
Jenkins：
执行：
mvn clean package
完成：
- 下载依赖
- 编译源码
- 单元测试
- 打包 Jar
如果：
这里失败。
流水线：
立即结束。
不会继续部署。
第五步：Docker 构建镜像
Jar 包成功之后。
Jenkins：
继续执行：
docker build
Docker：
根据：
Dockerfile
制作：
Docker Image。
此时：
应用已经拥有：
统一运行环境。
第六步：推送镜像（可选）
很多企业：
不会直接部署。
而是：
先上传镜像仓库。
例如：
Harbor
Docker Hub
阿里云镜像仓库
以后：
任何服务器。
都可以：
直接拉取。
统一部署。
第七步：部署测试环境
随后：
Jenkins：
执行：
docker run
或者：
docker compose up
新的容器启动。
测试环境：
更新完成。
此时：
测试人员：
开始验证功能。
六、为什么 Docker 一定要放在最后？
很多同学会问：
为什么不是：
先 Docker。
再 Maven？
原因很简单。
Docker：
负责运行程序。
Maven：
负责生成程序。
只有：
Jar 包已经生成。
Docker 才能：
制作镜像。
因此：
顺序必须是：
Git
↓
Compile
↓
Jar
↓
Docker Image
↓
Container
这是整个流水线中非常重要的一点。
七、天机学堂这一章到底在模拟什么？
如果把课程内容串起来。
其实就是：
模拟企业研发流程。
例如：
IDEA 编写代码
↓
Git Push
↓
Gogs
↓
Webhook
↓
Jenkins
↓
Maven
↓
Docker Build
↓
Docker Run
↓
测试环境
课程真正想表达的并不是：
如何安装 Docker。
而是：
企业如何实现自动化交付。
理解这一点之后。
再学习后面的 Kubernetes、Harbor。
都会容易很多。
八、企业为什么喜欢自动部署？
总结起来：
主要有四个原因。
① 提高效率
程序员：
不用：
重复：
打包。
复制。
启动。
部署。
② 降低人为错误
例如：
忘记：
更新代码。
复制错 Jar。
启动旧版本。
自动化：
全部避免。
③ 发布更加稳定
所有环境：
使用：
同一套：
Docker Image。
开发：
成功。
测试：
成功。
生产：
同样成功。
真正实现：
Build Once，Run Anywhere（一次构建，到处运行）。
④ 更容易回滚
如果：
新版本：
出现问题。
只需要：
重新启动：
旧镜像。
几分钟即可恢复。
而不是：
重新安装程序。
九、本章总结
现在，我们终于可以把三者串起来了。
开发人员
↓
Git Push
↓
Gogs
↓
Webhook
↓
Jenkins
↓
Git Clone
↓
Maven Build
↓
Docker Build
↓
Docker Image
↓
Docker Container
↓
测试服务器
↓
人工验证
↓
生产环境
整个过程中：
Docker、Gogs、Jenkins 并不是竞争关系。
而是：
分别承担：
不同职责。
| 工具 | 职责 |
|---|---|
| Docker | 提供一致的运行环境 |
| Gogs | 管理代码仓库 |
| Jenkins | 自动化执行流水线 |
三者结合之后：
企业便拥有了最基础的：
CI/CD 自动化研发能力。
💡 我的理解
很多初学者把 CI/CD 理解成 Jenkins，其实这是一个常见误区。
CI/CD 是一种开发理念，而 Jenkins 只是实现这种理念的工具之一。
除了 Jenkins，还有 GitLab CI、GitHub Actions、Azure DevOps、Tekton 等平台都可以完成相同的工作。
因此，学习天机学堂时，不要把重点放在“会不会点 Jenkins 页面”，而要理解它背后的思想：
把重复、标准化、可自动执行的工作交给机器，把时间留给开发者去解决真正的业务问题。
当理解了这一点，再学习 Docker、Harbor、Kubernetes，甚至云原生 DevOps，你会发现它们其实都围绕着同一个目标——提高软件交付效率和质量。
第四章：黑马天机学堂完整项目部署实战
——从本地开发到测试部署，彻底理解企业微服务开发流程
前三章我们已经分别介绍了企业开发模式、Docker、Gogs、Jenkins 以及 CI/CD。
这一章，我们将结合 黑马《天机学堂》 的项目，把这些知识串联起来。
当你理解了这一章，你会发现：
Docker、Gogs、Jenkins 从来都不是独立的软件，而是企业研发流程中的三个角色。
一、为什么黑马课程要搭建这么多环境？
很多同学第一次做到这一章时都会有这样的疑问：
为什么只是运行一个 Spring Boot 项目，却要安装 Docker、Gogs、Jenkins？
甚至会觉得：
「是不是课程为了增加难度，故意让我们学习这些工具？」
其实并不是。
黑马课程的目的并不是教你安装软件，而是在模拟真实企业研发环境。
因为企业开发从来都不是：
IDEA
↓
Run
↓
浏览器访问
而是：
开发
↓
提交代码
↓
自动构建
↓
自动部署
↓
测试验证
↓
发布生产
课程只是把企业每天发生的事情，浓缩到一个学习项目中。
二、天机学堂整体架构
在课程中，一个完整的系统通常包含：
前端(Vue)
│
▼
Gateway 网关
│
┌──────────┬──────────┬──────────┐
▼ ▼ ▼
用户服务 课程服务 交易服务
│ │ │
└──────────┴──────────┘
│
▼
MySQL / Redis / RabbitMQ / MinIO / Nacos
这里可以发现：
真正运行的不只是一个项目。
而是一整套微服务。
这也是为什么课程推荐使用 Docker。
否则：
每个服务都需要单独安装依赖。
整个环境会非常复杂。
三、课程为什么先部署 Docker？
很多初学者容易误解：
Docker 是部署工具。
实际上：
课程首先部署 Docker，是为了：
统一所有基础服务。
例如：
MySQL
Redis
RabbitMQ
Nacos
MinIO
这些基础组件。
都可以直接通过 Docker 启动。
例如：
docker compose up -d
几分钟内：
整个开发环境全部启动完成。
相比传统安装方式：
优势非常明显。
| 传统安装 | Docker 部署 |
|---|---|
| 手动安装多个软件 | 一键启动所有服务 |
| 容易出现版本冲突 | 所有人版本一致 |
| 重装系统重新配置 | 重新拉取镜像即可 |
因此：
Docker 在课程中承担的是：
统一开发环境。
四、为什么还要部署 Gogs？
当所有服务启动完成以后。
开发人员开始编写代码。
例如：
修改：
CourseService
完成之后：
执行：
git add .
git commit -m "新增课程查询接口"
git push
这里：
代码已经离开本地。
进入：
Gogs
很多同学以为：
流程已经结束。
实际上：
真正的自动化才刚刚开始。
五、Webhook：整个自动化流程的起点
Git Push 完成以后。
Gogs 会检测到：
新的 Commit
随后：
自动发送：
HTTP Request
通知：
Jenkins
这个动作：
就叫：
Webhook
可以理解成：
有人提交代码了。
快开始构建。
整个过程：
完全自动。
开发人员：
甚至不用打开 Jenkins。
六、Jenkins 自动开始工作
收到通知以后。
Jenkins：
立即启动流水线。
整个流程如下：
Git Clone
↓
Maven Clean
↓
Compile
↓
Package
↓
Docker Build
↓
Docker Run
↓
Deploy
这也是课程中：
Jenkins 任务配置的真正目的。
并不是：
为了学习 Jenkins。
而是：
模拟企业自动构建。
七、Maven 在这里做了什么？
很多同学认为：
Maven：
就是下载依赖。
其实：
企业中：
Maven 主要负责：
源码
↓
编译
↓
测试
↓
打包
↓
Jar
Jar 包：
就是：
Docker Build
需要的输入。
因此：
流程一定是：
Git
↓
Maven
↓
Jar
↓
Docker
顺序不能颠倒。
八、Docker Build 到底发生了什么？
假设：
项目已经打包成功。
随后：
Jenkins：
执行：
docker build -t tj-course-service .
Docker：
读取：
Dockerfile
例如：
FROM eclipse-temurin:17-jre
COPY target/*.jar app.jar
ENTRYPOINT ["java","-jar","/app.jar"]
随后：
生成：
Docker Image
镜像中已经包含：
- Java
- Jar
- 启动命令
以后：
任何服务器：
运行：
docker run
即可启动。
真正做到：
Build Once，Run Anywhere。
九、测试环境如何更新？
镜像构建完成以后。
Jenkins：
继续执行：
docker stop
停止旧容器。
随后：
docker rm
删除旧容器。
最后：
docker run
启动：
最新版本。
整个过程：
几乎不需要人工参与。
测试人员：
刷新浏览器。
即可：
开始测试。
十、如果测试失败怎么办？
很多初学者担心：
自动部署：
是不是很危险？
实际上：
企业都会：
保留：
旧镜像。
例如：
course-service:v1.0
course-service:v1.1
course-service:v1.2
如果：
最新版本：
出现 Bug。
只需要：
重新启动：
上一版本镜像。
即可：
快速回滚。
这也是 Docker 在企业中非常重要的一点。
十一、什么时候部署生产环境？
这一点：
不同企业：
有所不同。
通常：
流程如下：
开发
↓
测试环境
↓
测试通过
↓
预发布环境
↓
人工确认
↓
生产环境
互联网企业：
可能：
一天：
发布几十次。
传统企业：
可能：
一周：
发布一次。
但：
核心流程：
基本一致。
十二、把整个流程串起来
如果把前面所有内容连接起来。
最终得到的就是：
开发人员
↓
IDEA 编码
↓
Git Commit
↓
Git Push
↓
Gogs
↓
Webhook
↓
Jenkins
↓
Git Clone
↓
Maven Build
↓
生成 Jar
↓
Docker Build
↓
Docker Image
↓
Docker Run
↓
测试环境
↓
测试通过
↓
生产环境
这张图。
建议作为全文：
最重要的一张图。
十三、企业真实项目通常还会增加什么？
黑马课程为了方便学习。
已经省略了很多组件。
实际企业：
通常还会增加：
Harbor（镜像仓库）
SonarQube（代码质量）
Nexus（Maven 私服）
Kubernetes（容器编排）
Prometheus（监控）
Grafana（可视化）
ELK（日志）
整个流程：
会更加完整。
例如：
Git
↓
Jenkins
↓
SonarQube
↓
Docker Build
↓
Harbor
↓
Kubernetes
↓
Production
因此：
天机学堂其实只是：
企业 DevOps 的入门版本。
十四、本章总结
经过四章的学习，我们已经可以完整回答文章开头提出的问题：
企业为什么要使用 Docker、Gogs、Jenkins？
答案其实很简单：
因为它们分别解决了企业研发流程中的三个关键问题：
| 工具 | 企业价值 |
|---|---|
| Docker | 保证开发、测试、生产环境一致 |
| Gogs | 提供企业内部 Git 仓库，实现团队协作 |
| Jenkins | 自动执行构建、测试、部署流程 |
它们组合在一起，就形成了现代企业最基础的 CI/CD 自动化研发平台。
企业开发流程总结图
开发人员
│
IDEA 编写代码
│
▼
Git Commit / Push
│
▼
Gogs（代码托管）
│
Webhook 通知
│
▼
Jenkins 自动构建
│
┌──────────┼──────────┐
▼ ▼ ▼
Git Clone Maven Build Unit Test
│
▼
Docker Build Image
│
▼
Docker Run Container
│
▼
测试环境部署
│
▼
测试通过 → 发布生产
💡 我的理解
学习《天机学堂》这一章节时，不要只关注命令和配置。
课程真正想让我们理解的是一种企业研发思维：
- Docker 让环境标准化。
- Gogs 让团队协作有序。
- Jenkins 让重复工作自动化。
它们共同构成了一条从代码提交到自动部署的流水线。
未来当你继续学习 Harbor、Kubernetes、GitLab CI 或 GitHub Actions 时，你会发现它们并不是全新的知识，而是在这条流水线上的进一步扩展。
理解了流程，就理解了企业开发；理解了企业开发，再学习任何 DevOps 工具都会事半功倍。
第五章：企业真实项目还会有哪些组件？
在黑马《天机学堂》中，我们使用了：
- Docker
- Gogs
- Jenkins
- MySQL
- Redis
- RabbitMQ
- Nacos
这已经能够模拟一个基础的企业研发流程。
但在真实公司中，通常还会增加更多组件。
1. Harbor：企业镜像仓库
在课程中，Docker 镜像通常直接在 Jenkins 所在服务器运行。
而企业会把镜像上传到 Harbor：
镜像仓库（Harbor）
企业常用
作用
统一管理 Docker 镜像
优势
版本控制、权限管理、快速回滚
典型流程
Jenkins → Harbor → Kubernetes
这样：
- 测试环境拉取同一个镜像
- 预发布环境拉取同一个镜像
- 生产环境拉取同一个镜像
真正做到：
Build Once，Run Anywhere（一次构建，到处运行）
2. SonarQube：代码质量检查
Jenkins 在编译之前，往往会先调用：
SonarQube
静态代码分析
检查：
- 重复代码
- 潜在 Bug
- 安全漏洞
- 代码规范
如果质量不达标：
流水线直接终止
Fail
不会继续部署
3. Nexus：Maven 私服
企业内部通常不会每次都从 Maven 中央仓库下载依赖。
而是：
中央仓库
Nexus
开发者
中央仓库 → Nexus → 开发者
优势：
- 下载更快
- 减少外网依赖
- 可以管理公司内部 Jar 包
4. Kubernetes：容器编排平台
当天机学堂只有几个微服务时：
docker run
可以管理
如果有：
- 50 个微服务
- 200 个容器
- 多台服务器
就需要：
Kubernetes（K8s）
自动调度、扩容、重启、负载均衡
第六章：容易混淆的概念（强烈建议保留）
| 很多人认为 | 实际上 |
|---|---|
| Docker 是虚拟机 | Docker 是容器运行平台 |
| Docker 是部署工具 | 首先解决环境一致性 |
| Gogs 就是 Git | Gogs 是基于 Git 的代码托管服务 |
| Jenkins 是部署工具 | Jenkins 是自动化流水线平台 |
| CI = CD | CI 是持续集成，CD 是持续交付/部署 |
| Image = Container | Image 是模板，Container 是运行实例 |
| Docker Compose = Docker | Compose 是多容器编排工具 |
总结（升级版）
现在，我们终于可以用一句话概括整篇文章：
黑马《天机学堂》这一章，并不是在教你安装 Docker、Gogs、Jenkins，而是在模拟企业从开发到测试部署的完整研发流程。
核心流程
IDEA 编写代码
Git Commit / Push
Gogs 保存代码
Jenkins 自动构建
Maven 打包
Docker 构建镜像
启动容器
测试环境验证
发布生产
最终结论
| 工具 | 企业价值 |
|---|---|
| Docker | 保证开发、测试、生产环境一致 |
| Gogs | 提供企业内部 Git 仓库，实现团队协作 |
| Jenkins | 自动执行构建、测试、部署流程 |
真正需要理解的，不是三个工具，而是一条完整的企业研发流水线。
当你能够从 代码提交 一直讲到 Docker 部署、测试验证、生产发布 时，你对 Docker、Gogs、Jenkins 的理解，就已经超过了大部分只会配置命令的初学者。
更多推荐
8
0- 0
已为社区贡献11条内容
所有评论(0)