---

前言

Jenkins是一种开源自动化服务器，用于快速构建，测试和部署软件。它是一个基于Java的Web应用程序，可用于自动化构建，测试和部署软件的各个阶段。

Jenkins的核心功能是持续集成（CI），它使开发人员能够频繁地将代码更改集成到共享存储库中，并在每个更改中进行构建，测试和分析。Jenkins还支持持续交付（CD）和持续部署（CD），这意味着它可以将软件交付到生产环境中，而无需人工干预。

Jenkins具有丰富的插件生态系统，可以扩展其功能。它还支持多种版本控制系统（如Git，SVN等），并且可以与其他工具（如JIRA，SonarQube等）集成，从而提高整个软件交付流程的效率和可靠性。

使用Jenkins可以自动化大部分软件交付流程，减少人工干预的错误，并提高软件的质量和稳定性。

敏捷开发中的持续集成痛点
要理解敏捷开发，最好的切入点是知道：什么不是敏捷开发？

早些年，我参与过一个不小的项目，客户是一著名电视台。系统是用来支持当时大火的选秀节目，具体模块有场外观众短信支持，候选人得票情况的可视化显示，现场嘉宾的打分等子模块。总之，是一个功能蛮多，交互蛮复杂的系统。

因为在当年，选秀是一个新形态，所以作为开发人员，当然也不知道客户（电视台）想要的是什么东西。

但最糟糕的是，连电视台自己也不知道想要的东西具体长啥样？而且因为是搞艺术的，想象力自然丰富，

因此提的需求大概就是：
“要酷，要震撼，要能调动观众的积极性…”等等。总之就是需求很模糊，说不清楚。
但当时还不流行所谓的“敏捷开发”，常规的开发流程如下：

1. 需求分析
2. 设计
3. 编码
4. 测试
5. 交付

这也就是我们常说的“瀑布模型”。
可以现象，在该流程下，居于核心的就是需求分析。一旦需求分析出现大的偏差，之后的设计、编码、测试，即使做的再好，也是徒劳。因为你最后交付的根本不是用户想要的。
但是软件是这种东西，因为看不见摸不着。因而在具体的东西出来之前，大概率，用户根本就不知道自己想要的是什么。就好像电视台的工作人员，只知道 “酷、炸、炫”是他的需求，但如果再往具体处问，就不知道该说啥了。
但没办法，公司要挣钱，项目就一定要推下去，因此需求调研人员只能硬着头皮上。
虽然和电视台人员没少聊，但总体来说，也是言辞不详。最后的结果是，参考电视台的说辞，加上自己的猜测，再参考国外同类节目，晕晕沉沉弄了一个《需求分析》出来。
然后把《需求分析》传给了电视台，也不知道对方到底认真看了没有，反正最后的回复是：“没错，就是它，尽快出东西！”。
于是接下来，大家加班加点2个月，第一版终于出来了。欢天喜地给电视台看，本来大家的期望是掌声和赞美。但没想到，对方看了之后非常失望，说根本就不是他想要的东西。我们和对方争辩说，《需求分析》你也认可了，怎么可能不是你想要的东西呢？
结果对方也很委屈，答道：“《需求分析》我是看了，但这肯定不是想要的东西，你看这点…，这点…。”
原来，就这个《需求分析》来说，没想到同样的文字，不同人真会有不同的理解，甚至是完全相反的理解。
但这就是软件开发，因为看不见摸不着，高度定制，没有工业化标准。因此对用户来说，直到第一次看到实物（可运行的软件），才会逐渐在脑子中清晰他想要的是什么的东西。这就是软件开发的本质所在，没有任何人真的有错。但当时并不明白这个道理。
虽然很生气，奈何项目不小，对方又居于绝对强势。不爽归不爽，但回过头来，只有继续加班加点，吭哧吭哧的重新设计，重新编码。
因此，一个最初预期30个人月的项目，最终竟投入了100个人月还不止。
好在无论如何，最后，客户还是认可了我们的产品。但其中付出的辛苦，只有在身在其中，才会有真正明白。当然，人吃一个亏，总归会有些进步的。
因此，为避免再出现《需求分析》争议的情况，在之后项目中，在需求分析阶段，如果有可能，我们就会尽量的在《需求分析》中增加图示。如果项目不大，甚至会先做出一个原型出来。
当然，这些做法效果肯定是有的。但也并没有从根本上解决问题。之后的项目还是会有返工的情况出现，区别只是严重程度的大小而已。
而我后来明白，这种情况（返工），只要是在“瀑布模型”下，就无法根本避免，因为来自于以下事实：

1. 只要有沟通，就会有信息的变形，因此《需求分析》是不可靠的。
2. 即使《需求分析》是可靠的，随着项目的进展，竞争对手的出现，需求也可能过时。
3. 瀑布模型，这种自上而下的开发方式，无法响应这个快速变化的时代。

而要解决这个问题，就必须引入更轻便的开发方式，这就是“敏捷开发”。
但是普通人可能没想到，敏捷开发并没有定义具体的开发过程，而是起源于一个简单的理念（确实够敏捷的），这就是《敏捷宣言》：
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具；工作的软件 高于 详尽的文档；客户合作 高于 合同谈判；响应变化 高于遵循计划；也就是说，尽管右项有价值，我们更重视左项的价值。
而之后的各种方法论，其实都是为了践行这个原则。

敏捷冲刺

因为世界是易变的，因此敏捷开发就不提倡像“瀑布模型”那样，一开始就制定整个产品的详细开发计划。
而是提倡“小步快跑”的方式来实行整个产品功能。通过一个小计划接着一个小计划，通过反复迭代，最终
实现产品的自我“进化”，自我完善。
在敏捷开发中，我们把每个小开发计划，称为一个“冲刺”。而实践中，常见的冲刺时间是2周，最多不超
过1个月。
每个“冲刺”前，会有冲刺启动会，之后有总结会，一个冲刺的结束也是下一个冲刺的开始。同时，要在下
一次冲刺开始之前对上一次冲刺进行总结。然后根据总结情况，制定下一次冲刺的具体内容。
能够看出，这种短节奏、快调整的开发过程，相对于“瀑布模型”，最大的好处是灵活多变，反应敏捷。任
何时候，只要市场有变化，就马上调整下一步的开发计划。甚至是彻底放弃，及时止损。

精简文档
从事过开发的朋友都知道，文档是不可靠的。因为只要有文字，就会有曲解。更糟糕的是，面对快速的开
发节奏，文档往往不能及时跟进。而错误的文档还不如没有。
因此，在敏捷开发中，始终强调“可运行的软件胜过一切文档”，也提倡在客户、产品、开发之间，通过软
件本身来沟通。
因为是迭代式（冲刺）开发，因此每前进一步，都会有可运行的软件呈现。而软件是不会说谎的，因此就
从根本上避免了沟通误差的问题。

每日站会
因为敏捷开发强调沟通，因此团队就必须提供时间和场景供大家沟通，每日站会因此而生。
在站会上，任何人（产品经理，测试、工程师）都可以分享昨天他干了什么？有什么困难？有什么需要帮
助的？以及…
总之，就是通过及时的交流，把任何问题解决于无形之中。

敏捷教练
敏捷开发极度强调过程，强调沟通，强调团队合作。因此就需要有一个人站出来，作为敏捷过程的组织
者、督促者、协调者。这个人就是“敏捷教练”。
很重要的一点：敏捷教练不是官。而是接头人，是组织者。需要的不是权威，是责任心。

结对编程
敏捷开发极度强调沟通的价值，也相信在软件开发中，1+1 会大于2，尤其是在解决复杂问题的时候。因
此，在敏捷开发中，如果队员出现某些个人无法解决的难题，他可以申请结对编程。
具体的做法是一个编程，一个人在坐在旁边“指导”，然后过一段时间再交换。
这样，就会极大的避免面临复杂问题是，一个人思路彻底受阻，从陷入思维“死胡同”的情况出现。
.最后
当然，敏捷开发也绝不是解决一切问题的银弹，它也有自己的适用场景，具体来说，敏捷开发特别适合互
联网等市场竞争激烈，需要快速响应的场景。
但对另一些场景来说，强推敏捷流程则就会显得不切实际。
例如在航天航空领域，中途修改开发计划，要么是根本不可能，要么是要付出毁灭级的成本。因此，对这

---

一、安装jenkins

1. 部署中的痛点

为什么要用Jenkins？我说下我以前开发的痛点，在一些中小型企业，每次开发一个项目完成后，需要打
包部署，可能没有专门的运维人员，只能开发人员去把项目打成一个exe包，可能这个项目已经上线了，
需要把服务关，在部署到服务器上，将项目启动起来，这个时候可能某个用户正在操作某些功能上的东
西，如果你隔三差五的部署一下，这样的话对用户的体验也不好，自己也是烦的很，总是打包拖到服务器
上。希望小型企业工作人员学习一下，配置可能复杂，但是你配置好了之后，你只需要把代码提交到Git
或者Svn上，自动构建部署，非常方便。

2. 什么是jenkins

Jenkins是一个开源的、提供友好操作界面的持续集成(CI)工具，起源于Hudson（Hudson是商用的），主
要用于持续、自动的构建/测试软件项目、监控外部任务的运行（这个比较抽象，暂且写上，不做解
释）。Jenkins用Java语言编写，可在Tomcat等流行的servlet容器中运行，也可独立运行。通常与版本管
理工具(SCM)、构建工具结合使用。常用的版本控制工具有SVN、GIT，构建工具有Maven、Ant、
Gradle。

3. jenkins的安装和配置

这个jenkins我们不会直接安装在 192.168.0.104 我们会在一个新的虚拟机上运行 192.168.0.102，

（1）下载

Jenkins下载地址：http://jenkins-ci.org/ 或 https://mirrors.jenkins-ci.org/redhat/

（2）安装

# 安装java
[root@localhost ~] yum install java-11-openjdk-devel -y
# 查看java版本
[root@localhost ~] java --version
openjdk 11.0.16 2022-07-19 LTS
OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.el7_9) (build 11.0.16+8-LTS, mixed mode, sharing)

安装完之后注册登录

---

二、上传到运行服务器

1. jenkins构建服务器流程

2. 安装jenkins常用插件

安装常用插件

1. 汉化
   

2. ssh
   

3. git
   

4. ssh插件
   

3. 通过freestyle构建项目

在Jenkins的主界面上，点击“新建任务”或者“新建项目”，然后输入一个项目名称，并选择Freestyle项目类型。点击“确定”按钮。

添加git和ssh的凭证
在凭证管理页面中，点击“全局”或“系统”选项卡，根据需要选择要添加凭证的范围。

接着，点击“添加凭证”按钮，选择要添加的凭证类型，例如SSH用户名和密码、Git令牌等。

填写凭证信息，例如凭证ID、用户名、密码等，然后点击“确定”按钮。

注意：ssh配置中Remote Directory是目标服务器后进入的目录，我设置为了/data
注意：在Jenkins中添加凭证时，请注意保护您的凭证信息，不要将其暴露在公共场合。同时，及时删除不再使用的凭证，以免造成潜在的安全隐患。

配置Freestyle项目

在Freestyle项目的配置界面中，有多个选项可以配置。以下是一些常用的配置选项：

• 源代码管理：选择版本控制系统（例如Git、Subversion、Mercurial等），并填写仓库地址和认证信息。
• 构建触发器：定义何时触发构建操作，例如定期触发、代码提交触发、另一个项目构建完成触发等。
• 构建环境：定义构建环境，例如构建所需的JDK版本、构建参数、构建工具等。
• 构建步骤：定义构建操作的步骤，例如构建命令、测试命令、静态分析命令等。
• 构建后操作：定义构建完成后的操作，例如发送邮件、上传构建产物、部署应用程序等。

根据项目的需求，选择需要配置的选项，填写相应的信息即可。

保存配置

完成Freestyle项目的配置后，点击页面下方的“保存”按钮，保存配置。

执行构建

在项目的主页面上，点击“立即构建”按钮，即可执行构建操作。执行过程中，Jenkins会在控制台输出构建日志，方便查看构建的进展和结果。

通过以上步骤，您就可以使用Jenkins的Freestyle项目类型来构建您的应用程序。同时，Jenkins还支持其他类型的项目，例如Pipeline项目类型，它可以使用Groovy语言定义流水线式的构建过程，让您更加灵活地管理和执行构建操作。

4. 将构建服务器上的代码上传到运行服务器

根据上面的配置继续构建

在Jenkins的主界面上，点击“凭证”选项卡，然后点击“添加凭证”按钮，在“SSH Username with private key”选项中输入凭证信息，包括用户名、私钥、密码等，然后点击“确定”按钮。

在构建步骤中添加SSH连接命令

在Jenkins的项目配置页面中，进入“构建后操作”选项卡，选择“Send files or execute commands over SSH”选项。

然后填写SSH服务器的IP地址和SSH凭证信息，选择要执行的SSH命令，例如部署应用程序、重启服务等。

• Name：SSH Server的Name属性就是你希望连接的服务器。
• Source files：这里输入的是你希望传到服务器的文件夹和文件。路径是相对jenkins的orkspace的项目名称的。例如项
  目名称是Test_Project的go项目，编译打包后的路径为Test_Project文件夹下的target，则Surce files填入target/*.go。
• Remove prefix：如果Source files为target/*.jar，但是不想把target目录创建到服务器端，这个时候就可以在Remove prefix里填入target
• Remote directory：这里指定文件将被拷贝到服务器的路径。
  PS：被拷贝文件在服务器上的完整路径=登录服务器账号的默认路径+Remote directory。
• Exec command：这里就是连接服务器之后需要执行的命令。
  

在命令文本框中，可以使用Jenkins提供的环境变量或者构建参数等，以动态的方式组织SSH命令。

三、通过pipeline实现持续集成

Jenkins Pipeline是一种脚本化的工作流程，它可以通过代码来定义构建过程，包括构建、测试、部署等步骤。通过使用Pipeline，您可以将整个构建过程自动化，并将其保存在源代码控制库中，以便进行版本控制和追踪更改历史。

这比界面化操作带来的好处很多，比如jenkins挂掉了 我要进行修改和新增操作 这是使用pipeline会完成。如果在构建配置的时候jenkins挂掉了 界面化的操作配置会直接没了，pipeline就可以使用代码进行保存

把所有功能代码化后期存储和维护更加方便

1. 安装Pipeline插件：

2. 新建一个流水线任务：

3. Jenkins Pipeline参数

官方文档：https://www.jenkins.io/zh/doc/pipeline/tour/hello-world/

即使不熟悉Groovy也能完成流水线操作

选择hello world级别的语法

每一个stage都是一个操作

简单体验：
拉取 构建 部署

pipeline {agent anystages {stage('pull code') {steps {echo 'pull code'}}stage('build project') {steps {echo 'build project'}}stage('deploy project') {steps {echo 'deploy project'}}}
}

保存后直接构建：

4. 把freestyle级别的操作变成pipeline级别的操作

点击流水线语法把操作代码化

把git配置填充之前的配置 进行生成代码

保存后构建 在服务器里查看拉取的仓库

继续把构建和部署操作完成：
都是重复步骤
构建：

部署：

保存：

构建后去目标服务器查看：

四、通过jenkinsfile管理构建pipeline脚本

使用Jenkinsfile来管理构建Pipeline脚本有许多好处，其中一些包括：

1. 管理代码版本：Jenkinsfile可以存储在代码版本控制系统中，因此您可以将Pipeline脚本与应用程序代码一起管理，从而使得管理代码变得更加容易。

2. 可重复性：使用Jenkinsfile可以确保每次构建都具有相同的设置和步骤，从而提高构建的可重复性。这是因为Jenkinsfile是一个文本文件，可以轻松地跟踪和管理。

3. 可维护性：将Pipeline脚本与应用程序代码一起管理可以使其更易于维护。这是因为您可以使用与应用程序相同的工具和流程来管理Jenkinsfile。

4. 更好的可视化：使用Jenkinsfile可以提供更好的可视化功能，因为您可以将整个Pipeline脚本作为代码存储，从而使得整个流程更加透明和易于理解。

5. 可编程性：Jenkinsfile是基于Groovy编写的，这意味着您可以使用编程语言的所有功能来编写Pipeline脚本。这为您提供了更多的灵活性和自定义选项。

6. 持续交付：Jenkinsfile使得自动化持续交付变得更加容易，因为您可以使用Jenkinsfile来定义整个CI/CD Pipeline，从代码检查到测试和部署。

总之，使用Jenkinsfile管理构建Pipeline脚本可以使您的构建过程更加可重复、可维护和可视化，并提供更多的灵活性和自定义选项，以实现自动化持续交付。

仓库新建Jenkinsfile文件

把Groovy语法复制到这里

修改流水线配置

保存后运行到目标服务器查看（重复操作，自己看即可）

定时构建和轮询SCM构建

定时构建和轮询SCM构建是Jenkins中两种不同的构建触发方式。

1. 定时构建：Jenkins中的定时构建是指在指定的时间执行构建操作。您可以在Jenkins的构建配置中设置一个时间表，例如每天晚上10点或每个星期五上午8点，以触发构建操作。这种方式通常用于定期构建或者需要按照时间表进行构建的情况。

2. 轮询SCM构建：Jenkins中的轮询SCM构建是指在一定时间间隔内轮询代码版本控制系统中是否有代码变更，并在检测到变更时触发构建操作。您可以在Jenkins的构建配置中设置轮询间隔和代码版本控制系统的位置，例如每分钟检查一次Git代码库中是否有代码变更。这种方式通常用于需要及时构建并测试新代码的情况。

在选择构建触发方式时，您需要根据自己的需求和构建场景来选择适合的方式。如果您需要按照特定时间表执行构建操作，则应使用定时构建。如果您需要及时检查并构建最新代码，则应使用轮询SCM构建。

五、通过jenkins部署go和vue

1. 有哪些服务器我们需要部署？

部署流程：