Jenkins工作过程(待更新)

消除知识碎片化

1，现实的工作中，

　　　一个团队往往有多个团队成员

　　　团队成员往往有多种角色：产品，后端，前端，UI，测试，运维

　　　一个项目往往有多个阶段：需求阶段，评审阶段，编码阶段，测试阶段，部署阶段

　　　一个项目有多个环境：本地调试环境，开发环境，测试环境，预发布/生产环境

2，CI（持续集成）

　　集成，每个团队成员将手中任务编码，单元测试完成后；将自己的完成的工作集成在一起；项目迭代内容集成在一起交由测试人员进行测试；

　　说通俗点，把整个迭代所有团队成员的完成的内容集成在一个环境交给测试人员进行测试

　　传统集成：

　　　　1，每个开发人员改完一部分内容，将代码编译，在本地进行测试；

　　　　2，每个开发人员开发完自己的工作之后，迁入合并代码；拉取最新代码；

　　　　3，编译打包

　　　　4，手动部署每一个服务到测试环境进行测试

　　持续集成：

　　　　1，每个人开发一部分工作之后，将代码迁入合并；

　　　　2，Jekins自动构建代码，部署到测试环境

　　　　3，整个过程强调自动化，开发人员只需要迁入自己的修改

　　　　4，自动化的代码测试

　　　　5，快速确保迁入的内容是合格的

2，CD（持续交付）

　　所有迭代或者项目内容测试完成之后，确保有一个可随时部署到生产环境的代码库或编译版本

3，CD(持续部署)

　　将交付的结果部署，自动化的部署到生产环境；任何一个更改都可以在任何时候进行部署

4，CI/CD

　　强调的是整个过程的流水线集成，过程自动化；这种自动化的过程尤其对于大型项目，大型团队，多个服务时会带来更高效的开发人员，测试人员，运维人员之间的合作

　　DevOps是CICD思想的延伸，CICD是DevOps的基础核心，

　　如果没有CICD自动化的工具和流程，DevOps是没有意义的

5，大公司的CICD往往做的比较复杂；它们会包括docker，k8s，云，git，jenkins，镜像仓库等

　　但它们的最简化的流程则是git，jenkins，本地IDE；

　　

6，环境

　　windows10（本机）

　　Jenkins 2.249（安装在本机）

　　Centos7（阿里云）

　　github

　　dotnet core3.1

7，安装Jenkins2.249

　　因为主要是说Jenkins的配置，对于Jenkins的是在windows10上安装还是Linux是就没有那么去讲究，选择的是windows版本

　　安装中可能会踩的一些坑

　　1，建议使用cmd命令行管理员权限安装msi(msiexec package /"路径")

　　2，端口号：默认是8080，如果你的8080经常被占用，建议换个端口

　　3，解锁Jenkins；直接复制提示的路径到文件夹时，如果你使用的不是管理员权限安装，这些文件夹需要一个个的打开，因为需要权限

　　　　

　　4，自定义Jenkins，推荐安装默认插件(建议安装)

　　　　

　　5，创建管理员

　　　　

8，配置全局Git路径

　　打开Global Tool Configuration

　　　　Global Tool Configuration用于配置Jenkins要使用到的工具，主要包括JDK，Gi，Maven，Gradle，Ant等

　　　　配置git程序路径（（git在window系统中的默认路径：C:\Program Files\Git\bin））：C:\Program Files\Git\bin\git.exe；

　　　　配置完成后保存

　　

　　jenkins在构建时，会调用配置的git程序，拉取最新代码进行构建部署

　　

8，Jenkins配置项目构建

　　在菜单中选择""新建Item"

　　

　　在弹出的对话框中，输入构建的名字，如"test","School.ApiServer"等

　　并选择类型"Freestyle project"

　　

　　

　　General：

　　　　描述：用于描述项目的信息，类似于备注

　　　　配置源码仓库：示例github的https源码仓库地址

　　　　

　　　　如果你需要使用参数，可以使用"This project is parameterized"

　　　　这里仅仅是举例，我实际上使用的是上面的"github项目"的配置

　　　　

　　源代码管理：

　　　　配置github源代码管理

　　　　选择"git"；在Repostory URL输入项目的https git仓库地址

　　　　选择凭据：github的账户与密码；如果你是第一次添加，或者想使用其他github账户，可以选择"添加"(参考下面的一个图片)

　　　　选择你需要构建的分支：这里使用的是main分支

　　　　

　　　　添加新的github账户

　　　　

　　构建触发器

　　　　构建触发器

　　　　包括定时触发（Build periodically）：示例，每30分钟一次， "H/30 * * * *"

　　　　提交到github时触发（GitHub hook trigger for GITScm）

　　　　定时检查版本库（Poll SCM）

　　构建环境（略）

　　构建流程

　　

　　构建步骤：

　　配置.Net Core的构建步骤

　　添加Execute Windows batch command　　　　　

　　　　　　图示的构建命令含义：

　　　　　　1，编译工作目录下的项目

　　　　　　2，删除上层发布目录的文件

　　　　　　3，将工作目录下Demo.Core.ApiServer项目进行发布，发布文件目录到"工作目录下的Webbuild"目录下

　　　　　　4，变量工作目录(WORKSPACE)的值：示例：C:\Users\Administrator\AppData\Local\Jenkins.jenkins\workspace\test\

　　　　　　　　其中test为我们在jenkins的项目名称，jenkins在工作时，会将代码拉取到WorkSpace目录下进行构建操作

　　　　　　

echo "开始编译代码"
dotnet build "%WORKSPACE%"
echo "删除上次发布后的文件"
rmdir /s/q "%WORKSPACE%\microservice\"
echo "开始发布代码"
dotnet publish "%WORKSPACE%\demo\demo.csproj" -c release -o "%WORKSPACE%\wwwroot\"

　　重要：　　

　　　　上面的命令仅仅是将.NET Core程序进行了编译，并发布到工作目录下的Webbuild目录下，它的工作方式有点类似与Visual studio的发布过程：编译->发布到项目目录下

　　　　然而上面的命令并没有把发布后的结果部署到IIS或者其他Web服务器的站点目录文件

　　　　要想将发布结果部署到Web服务器上，这个打包过程有三种方式

　　1，如果web服务器是和Jenkins同一台机器（如果你在本机做测试），那么只需要使用简单的文件复制

　　　　　　示例：window系统下，复制到IIS的部署目录（如下，H:\Web\DemoCore为IIS的部署目录）

copy %WORKSPACE%\Webbuild\*  H:\Web\DemoCore\

　　2，通过FTP(Publish over FTP)

　　　　　　首先需要安装Publish over FTP插件

　　　　　　在插件管理器中安装

　　　　　　

　　　　　　

　　　　　　　　

　　　　　　　　配置FTP服务器，在"ConfigSystem"中配置"Publish over FTP"；如下

　　　　　　　　很重要：注意你的FTP配置的端口和使用过程中的安全性，本文仅仅是个人用于研究Jenkins的构建部署工作过程，所以没有去考虑安全性

　　　　　　　　

 

　　　　　　　　在构建步骤中，添加后续构建步骤

　　　　　　　　

　　3，通过SSH(Publish over SSH)

　　　　略

　　重启Web服务器(IIS为例)

　　当你将文件复制到Web服务器时，如果Web服务器正在使用中，那么复制文件到web服务器站点目录下将会失败

　　1，使用远程powershell（psexec）重启IIS（不安全，因为用户，密码什么都配置在里面了，引用自他人文章https://blog.csdn.net/ma_jiang/article/details/53955504）

psexec \\192.168.0.xxx -u Administrator -p xxxx cmd

iisreset /stop
iisreset /start

当然在jenkins 可以这样用psexec \\192.168.0.xxx -u Administrator -p xxx iisreset /stop

 　　你也可以不重启IIS，转而重启项目对应的应用程序

D:\NodeJS\psexec \\192.168.0.12X -u Administrator -p XXX c:\windows\system32\inetsrv\AppCmd.exe stop apppool /apppool.name:"xxx"

jenkins CIFS Publishers 拷贝文件

D:\NodeJS\psexec \\192.168.0.12X -u Administrator -p XXX c:\windows\system32\inetsrv\AppCmd.exe start apppool /apppool.name:"xxx"

　　2，使用Powershell是不安全的，因为你把用户，密码都往命令行里面配了，在Jenkins的控制台，你可以看到构建时执行的命令和配置的账户密码

　　　　使用curl.exe向服务器发送请求，用自己做的小工具在服务器上接收到请求后重启IIS

　　　　curl.exe安装：https://curl.haxx.se/windows/

　　　　同时在服务端自己写一个小工具做安全检查和web站点的暂停和启动

 

　　N，Jenkins构建.NetCore项目，部署在IIS上，IIS与Jenkins在同一台机子上的构建“Execute Windows batch command”命令示例　　　　

echo "开始编译代码"
dotnet build "%WORKSPACE%"
echo "删除上次发布后的文件"
rmdir /s/q "%WORKSPACE%\Webbuild\"
echo "开始发布代码"
dotnet publish "%WORKSPACE%\Demo\Demo.csproj" -c release -o "%WORKSPACE%\Webbuild\"
echo "暂停IIS"
iisreset /stop
echo "开始复制到Web目录，IIS目录H:\Web\Demo"
copy %WORKSPACE%\Webbuild\*  H:\Web\Demo\
echo "复制到Web目录完成"
iisreset /start
echo "启动IIS完成"

其他：

　　发送邮件通知

　　sonar代码扫描

　　私有Nuget