🚀 Jenkins 快速入门与前端部署自动化指南

---

📌 一、Jenkins 基础环境

• 服务器：10.0.0.72
• 配置：2C4G
• 角色：Jenkins 主节点 + GitLab

# 准备JAVA11环境
yum install -y java

# 查看文件
ll
-rw-r--r-- 1 root root 211076319  4月  8 08:32 jenkens-2.387.1-lts-plugins.tar.gz
-rw-r--r-- 1 root root  98140293  4月  8 08:32 jenkins-2.387.1-1.1.noarch.rpm
# 启用并启动Jenkins服务
systemctl enable --now jenkins

# 检查Jenkins状态
systemctl status jenkins

# 解压插件到指定目录
tar xf jenkens-2.387.1-lts-plugins.tar.gz -C /var/lib/jenkins/plugins/

# 修改目录权限
chown -R jenkins.jenkins /var/lib/jenkins/plugins/

# 重启Jenkins服务
systemctl restart jenkins

# 获取初始管理员密码
cat /var/lib/jenkins/secrets/initialAdminPassword

---

📌 二、Jenkins 参数化构建流程

1. 复制已有项目

选择 "复制已有的项目" → 勾选 This project is parameterized。

2. 参数设置

• Git Parameter：

  • 变量名：GIT_TAG
  • 类型：Tag
  • 排序：降序

• Choice Parameter：

  • 名称：choice
  • 选项：deploy、rollback

---

📌 三、Jenkins 自动触发任务流程

1. 使用 GitLab Webhook 自动触发

• 在 Jenkins 项目中配置：

  Build when a change is pushed to GitLab
  Webhook URL: http://10.0.0.72:8080/project/autobird
  Token: 61196b06eb3f174a726fe75f37cd0f8b

• GitLab 中配置 Webhook：
  • URL 填上方地址
  • 勾选 Push events
  • 本地 GitLab 允许访问 Jenkins 的内网地址

• GitLab 中配置 Webhook：
  • 效果

---

📌 四、前端部署流程（无 Docker）

1. 安装 Node.js

tar xf node-v16.19.1-linux-x64.tar.xz -C /app/tools/
ln -s /app/tools/node-v16.19.1-linux-x64 /app/tools/node
chown -R root.root /app/tools/node*
echo 'export PATH=/app/tools/node/bin/:$PATH' >> /etc/profile
source /etc/profile

2. 设置国内 npm 源

npm config set registry https://registry.npmmirror.com

---

📌 五、Jenkins 构建流程脚本（deploy + rollback）

# 变量定义
CODE_TAR=/opt/china_${GIT_TAG}.tar.gz
WEB_CODE_SRC=/opt/china_${GIT_TAG}
WEB_CODE_DIR=/app/code/china
WEB_CODE_DIR_BAK=/app/code/china_bak/
ip_list=10.0.0.7
export PATH=/app/tools/node/bin/:/app/tools/maven/bin/:$PATH

1. deploy() 函数（部署）

npm i
npm run build
cd dist
tar zcf ${CODE_TAR} .

for ip in $ip_list; do
    scp $CODE_TAR root@$ip:/opt/
    ssh root@$ip "mkdir -p ${WEB_CODE_SRC}; tar xf ${CODE_TAR} -C ${WEB_CODE_SRC};         [ -e ${WEB_CODE_DIR} ] && 
m -rf ${WEB_CODE_DIR};         ln -s ${WEB_CODE_SRC} ${WEB_CODE_DIR};         echo ${WEB_CODE_SRC} >> /opt/deploy.log"
done

2. rollback() 函数（回滚）

for ip in $ip_list; do
    ssh root@$ip "
m -rf ${WEB_CODE_DIR};         WEB_CODE_OLD=\`tail -2 /opt/deploy.log | head -1\`;         ln -s \$WEB_CODE_OLD ${WEB_CODE_DIR}"
done

3. 入口判断逻辑

case "${choice}" in 
    deploy) deploy ;;
    rollback) rollback ;;
    *) echo "非法参数: 应为 deploy 或 rollback" ;;
esac

---

📌 六、Node 节点配置（分布式 Jenkins）

添加 Node 步骤：

1. 系统管理 → 节点管理 → 新建节点
2. 填写信息：
   • 类型：Permanent Agent
   • 工作目录：/tmp/
   • 启动方式：Launch agent via SSH
   • 凭据：root 用户账号密码
   • Host Key Verification Strategy：选择 Non verifying

⚠️ 注意：如无 JDK，Jenkins 会尝试下载，但下载失败会导致连接问题，需手动配置 JDK。

---

📌 七、打包结果目录示例

china-ex-main/
├── dist/
│   ├── 脚本.js
│   ├── 样式.css
│   ├── 字体.woff
│   └── index.html
├── node_modules/
├── package.json
└── README.md

dist/ 目录为前端编译后静态资源文件，需部署至 nginx 等中间件服务。

用户管理与权限设置（RBAC）

基于角色的访问控制（RBAC）是 Jenkins 中常用的权限管理方式，可实现不同用户对系统资源的精细化控制。

---

🧩 1. 检查插件与授权策略

插件检查

确保已安装以下插件：

• Matrix Authorization Strategy Plugin
• Role-based Authorization Strategy Plugin（推荐）

开启 RBAC 授权策略

• 进入 系统管理 -> 全局安全配置
• 授权策略选择：Role-Based Strategy
• 保存配置

💡 注意：默认安装后 Jenkins 所有用户拥有最高权限，必须开启授权策略进行权限收缩管理。

---

📜 2. 添加角色与权限

进入 系统管理 -> Manage and Assign Roles -> Manage Roles：

添加全局角色（Global roles）

• 角色名：如 developer
• 选择权限项，例如：
  • Overall -> Read
  • Job -> Build, Job -> Read, Job -> Discover
  • View -> Read

点击保存。

---

👥 3. 添加用户并与权限关联

添加用户 dev01

进入 Jenkins 管理后台：

• 系统管理 -> 管理用户 -> 创建用户
• 用户名：dev01
• 填写密码、邮箱等信息

---

关联角色权限

进入 系统管理 -> Manage and Assign Roles -> Assign Roles：

• 在 Global roles 中为 dev01 用户分配角色：
  • 用户名：dev01
  • 对应勾选 developer 角色
• 可选：在 Project roles 或 Folder roles 中配置任务级别的权限

---

🧪 4. 登录调试验证

• 使用 dev01 用户登录 Jenkins
• 验证是否具有期望的权限（如是否可查看任务、是否能构建任务等）

---

🛡️ 建议使用“最小权限原则”，仅授予用户其实际所需的最小权限。

发布策略

全量发布（Full Release）

全量发布是一种将新版本应用或系统一次性推送给所有用户的发布策略。在这种方式下，所有用户在同一时间接收到更新，无需分批次或阶段性推广。全量发布通常适用于更新频率较低、对版本稳定性要求较高的应用场景。

---

灰度发布 / 金丝雀发布（Canary Release）

概念：
灰度发布（或金丝雀发布）通过只将新版本推送给部分用户或流量进行验证，进而逐步扩大新版本的覆盖范围。

• 最初只在部分服务器上部署新版本，或只向部分用户开放（例如 5% 或 10% 的流量）；
• 根据监控指标（如错误率、响应时间等）判断是否可以继续扩大覆盖范围。

---

滚动更新（Rolling Update）

概念：
滚动更新是一种逐步替换旧版本实例的策略，在不中断服务的情况下更新整个系统。

• 每次只更新一小部分实例（例如一个或几个容器），在此过程中维护集群内服务的可用性；
• 等待更新实例稳定后，再继续下一批实例的更新，直至完成所有实例的切换。

---

A/B 测试部署（A/B Testing Deployment）

概念：
A/B 测试部署更多关注产品和用户体验，通过同时运行两个不同版本的应用（版本 A 与版本 B），并将用户随机分组，让一部分用户体验新版本，另一部分使用旧版本，从而收集对比数据。

• 随机分配用户到 A 组或 B 组；
• 收集并分析关键业务指标（如转化率、点击率、错误率等）；
• 根据测试结果决定是否全面上线新版本或继续优化。

---