请教 jenkins 发布流程的问题

应该是 B

在 A 上完成的

A 啊。。。肯定不是 B，B 负责拉 war 包就行。或者手动给 copy 过去。

1，2 在 A 上完成，此谓 CI


打包后的东西：
从 A 上传输到 B 上；
或者从 A 上传输到制品库，再使用 B 从制品库拉取。
最后在 B 上启动。
此谓 CD

公司目前都是在 A 上面做这些操作

B 上完成的，A 的工作就是任务发布，然后把执行脚本同步给 B，然后 B 去执行脚本，拉代码和打包。

a 啊，jenkins 有 git 、maven 插件支持 pull 、打包、编译等

A 啊, B 上还有线上程序跑着, 编译打包很容易跑满 CPU 的.

看起来关键分歧在如何理解“配置了节点 机器 b 的信息”，如果这里指的是 jenkins 的 slave 节点，那么在 B 上运行 1 和 2.
但后面提到只是在 B 上运行，那边 B 就仅仅是部署机，1 和 2 在 A 上运行。
所有关键是，“配置了节点 机器 b 的信息”具体指什么

用 B 的怕不是来搞笑的吧，如果有很多 B，那不是每台服务器都要编译打包一次，浪费资源不说，怎么保证打包出来的程序不受系统环境的影响

A.

需要打包的肯定在 A 上处理, A 上拉取代码 /编译打包, 然后部署到 B

9 楼+1，如果 B 是 jenkins 从属节点则在 B 上执行整个部署流程。

如果 B 只是普通服务器节点，则整个代码拉取打包的过程均在 jenkins 节点也就是 A 节点上完成，打包完成后在将包 push 到 B 节点运行。

A 只是作为一个 master 用于发布任务,具体的任务需要 B 也就是 slaver 去执行

这样不会对 master 造成压力

涨知识了

正常的操作逻辑：在 A 上面打包成 jar 或者 war，然后上传到 B 发布。

你非要通过 A 控制 B 去 pull 源代码打包发布也不是做不到，但会比较麻烦就是了。

在 A 上完成 git 代码更新和编译打包，再把包部署到 B 。
B 是生产环境机器，一般不会去做编译打包，也不用安装 git 命令和 Maven 。

jenkins 调度可以指定节点的。默认应该是 master 或者随机

首先不能在 B 上执行，打包过程可能会占用过多资源，会影响 B 上的服务。
实际上应该有个打包机 C，CPU 和磁盘性能最好好些，然后所有项目的打包任务都调度到 C 上。
A 只负责调度，将对应任务调度到 C 上打包，打包完后再由 A 调度部署在 B 上。

现在机器 a 上装了 jenkins 其中配置了节点 机器 b 的信息，想要在机器 b 上发布项目

1. A 机器通过 webhook 到 git 上拉取代码

2.通过 pipeline 或者配置好的命令来通过 Maven 、Ant 、Gradle 打包

此时 jekins 已经完成 CI 的持续集成。

3.通过配置 B 节点通过 docker 、k8s 等实现容器构建部署，相当于把 A 构建好的包下载到 jvm 容器内运行。

另我不同意打包机的观点，大部分情况是节点 A 机器已经基本够用，不够就扩展，又不是做 devsecops