---

前言

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实现持续集成