Jenkins基础教程（47）Jenkins设置构建作业之创建自由式构建作业：Jenkins构建大法：自由风格项目带你轻松玩转自动化

最新推荐文章于 2025-11-24 20:51:43 发布

原创最新推荐文章于 2025-11-24 20:51:43 发布 · 239 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#jenkins #自动化 #servlet

Jenkins基础教程专栏收录该内容

185 篇文章

订阅专栏

每次手动打包部署到深夜，你是否也曾仰望星空思考：为啥不让Jenkins这个贴心小助手来干活？

第一章：认识Jenkins，你的构建管家

1.1 Jenkins是什么？

简单来说，Jenkins就是一个用Java编写的开源持续集成（CI）和持续交付（CD）工具。它可以监控代码变更，自动执行构建、测试和部署任务，就像一位忠实的构建管家，时刻准备为你服务。

想象一下，你刚刚把代码推送到Git仓库，Jenkins就像被按下了启动按钮，立刻开始工作：拉取最新代码、解决依赖关系、运行测试、打包部署，一气呵成。而你，只需要悠闲地品着咖啡，等待构建结果的通知。

1.2 为什么选择自由风格项目？

在Jenkins的世界里，有多种构建作业类型，其中自由风格软件项目是最灵活、最易上手的一种。它可以用于任何类型的项目，配置简单直观，非常适合初学者入门。

自由风格项目的优势：

可视化配置：通过Web界面点点选选就能完成配置，无需编写复杂脚本
灵活性强：支持各种源码管理工具、构建触发器和构建步骤
生态丰富：可以安装插件扩展功能，满足不同需求
易于调试：每个构建步骤的结果清晰可见，问题定位方便

第二章：Jenkins环境准备，打好地基

2.1 安装Jenkins

Jenkins的安装非常简便，这里以最常见的War包方式为例：

下载Jenkins：访问Jenkins官网，下载最新的War文件
运行Jenkins：在命令行中切换到War文件所在目录，执行以下命令：

java -jar jenkins.war

如果需要修改端口，可以使用：

java -jar jenkins.war --httpPort=8081

通过Tomcat运行：你也可以将Jenkins War文件放入Tomcat的webapps目录中，通过Tomcat来启动

2.2 初始设置

首次访问Jenkins（通常是http://localhost:8080），会进入初始化设置向导：

解锁Jenkins：从Jenkins控制台日志中获取初始管理员密码，在解锁页面输入
安装插件：建议选择"安装推荐插件"，这会安装最常用的插件集合
创建管理员用户：设置你的管理员账号和密码，以后就用这个账号登录

2.3 检查插件安装

为确保自由风格项目的完整功能，请检查以下关键插件是否已安装：

Git插件：用于从Git仓库拉取代码
Credentials插件：安全管理各种凭证
Email Extension插件：邮件通知功能
Workspace Cleanup插件：清理工作空间

如果缺少某些插件，可以在"系统管理" → "插件管理"中搜索安装。

第三章：创建第一个自由风格构建作业

3.1 新建项目

让我们开始创建第一个自由风格项目：

在Jenkins主页面，点击左侧菜单的"新建任务"
输入任务名称，例如"My-First-Freestyle-Project"
选择"构建一个自由风格的软件项目"
点击"确定"进入配置页面

命名技巧：任务名称应有明确含义，便于后续识别和管理。注意创建后不要轻易更改名称，因为很多内部文件都是以任务名称命名的。

3.2 通用配置(General)

在通用配置部分，我们需要设置一些项目的基本信息：

项目描述：简要描述项目的用途，例如"这是一个示例前端项目，用于演示Jenkins构建流程"
丢弃旧的构建：这是重要的维护设置，可以防止构建历史占用过多磁盘空间。建议设置：

- 保持构建的天数：7天
- 保持构建的最大个数：10-20个

参数化构建：如果需要根据不同参数执行不同构建流程，可以在这里定义参数。例如，定义部署环境参数（开发/测试/生产）。

3.3 源码管理(Source Code Management)

这是自动化构建的关键——告诉Jenkins从哪里获取代码：

选择Git（如果你使用其他版本控制系统，如SVN，请选择对应选项）
在Repository URL中输入你的代码仓库地址
配置认证信息：

- 如果使用SSH认证，需要添加SSH私钥
- 如果使用HTTP认证，需要添加用户名和密码

常见问题解决：如果出现认证失败，可以尝试以下方法：

安装Github Authentication plugin等认证插件
检查Jenkins服务的运行用户，确保它有访问代码仓库的权限
如果是主机名解析问题，需要在/etc/hosts中添加IP和主机名的映射

3.4 构建触发器(Build Triggers)

构建触发器决定何时启动自动构建，常见的触发器有：

定时构建：像cronjob一样按计划执行，例如每15分钟一次：H/15 * * * *
轮询SCM：定期检查代码仓库是否有变更，有变更则构建
GitLab webhook：当代码推送到GitLab时，自动触发构建
其他项目触发：当其他项目构建完成后触发当前项目

3.5 构建环境(Build Environment)

根据项目需求勾选相应的构建环境选项：

Delete workspace before build starts：构建前清理工作空间
With Ant：使用Ant构建工具
Add timestamps to the Console Output：在控制台输出中添加时间戳

3.6 构建(Build)

这是构建过程的核心部分，可以添加多个构建步骤：

对于自由风格项目，最常见的构建步骤是执行Shell脚本或Windows批处理命令。

示例Shell脚本：

echo "开始构建..."
# 显示构建信息
echo "当前工作目录：$(pwd)"
echo "构建编号：$BUILD_NUMBER"

# 安装依赖
npm install

# 运行测试
npm test

# 构建项目
npm run build

echo "构建完成！"

注意：Jenkins执行Shell脚本时，默认工作目录是Jenkins主目录/workspaces/以job名称命名的文件夹。

3.7 构建后操作(Post-build Actions)

构建完成后，我们通常需要做一些后续工作：

归档制品：将构建产物（如JAR、WAR文件）保存起来
发布JUnit测试结果报告：如果项目有单元测试，可以生成测试报告
邮件通知：将构建结果通知相关人员
触发其他项目：构建成功后自动触发下游任务

第四章：实战演练，完整示例

4.1 项目背景

假设我们有一个简单的HTML前端项目，代码存放在GitLab上。现在需要配置Jenkins实现以下目标：

当代码推送到GitLab时自动构建
执行构建过程（依赖安装、代码检查）
将构建产物部署到Web服务器
构建结果通过邮件通知团队

4.2 详细配置步骤

4.2.1 项目基本信息

项目名称：frontend-deployment-pipeline
描述：前端项目自动化构建与部署

4.2.2 源码管理配置

Repository URL: git@gitlab.example.com:your-group/your-frontend-project.git
Branch Specifier: */main
Credentials: 选择已配置的SSH密钥

4.2.3 构建触发器

勾选"GitLab webhook"，记下URL和Token，用于在GitLab中配置webhook。

4.2.4 构建脚本

添加Execute Shell构建步骤，输入以下脚本：

#!/bin/bash
echo "========== 开始前端项目构建 =========="

# 显示环境信息
echo "当前工作目录：$(pwd)"
echo "Node版本：$(node --version)"
echo "NPM版本：$(npm --version)"

# 安装依赖
echo "步骤1：安装项目依赖..."
npm install

# 代码检查
echo "步骤2：执行代码检查..."
npm run lint

# 运行测试
echo "步骤3：运行单元测试..."
npm test

# 构建项目
echo "步骤4：构建生产版本..."
npm run build

echo "========== 构建阶段完成 =========="

# 部署到Web服务器
echo "步骤5：部署到Web服务器..."
# 定义目标服务器和项目名称
TARGET_SERVER="user@webserver-ip"
PROJECT_NAME="frontend-$(date +%Y%m%d-%H%M%S)"

# 在目标服务器创建目录
ssh $TARGET_SERVER "mkdir -p /var/www/$PROJECT_NAME"

# 上传构建结果
scp -r dist/* $TARGET_SERVER:/var/www/$PROJECT_NAME/

# 切换软链接指向新版本
ssh $TARGET_SERVER "cd /var/www && rm -f html && ln -s $PROJECT_NAME html"

echo "========== 部署完成 =========="
echo "项目已成功部署到：/var/www/$PROJECT_NAME"
echo "可通过访问 http://webserver-ip 查看最新版本"

注意：为确保脚本顺利执行，需要：

在Jenkins服务器上安装Node.js和npm
配置Jenkins服务器到目标Web服务器的SSH免密登录
在目标服务器上提前创建/var/www目录并设置适当权限

4.2.5 构建后操作

归档制品：配置归档dist/**目录下的所有文件
邮件通知：

- 收件人：team@example.com
- 通知时机：仅当构建失败或不稳定时发送

4.3 GitLab webhook配置

为了让GitLab在代码推送时能通知Jenkins，需要在GitLab项目中配置webhook：

进入GitLab项目设置 → Webhooks
输入Jenkins提供的URL和Token
选择触发事件：Push events
添加webhook并测试

4.4 邮件通知配置

在Jenkins系统设置中配置邮件服务器：

SMTP服务器：根据你的邮箱提供商填写，如smtp.qq.com
认证信息：

- 用户名：你的邮箱地址
- 密码：QQ邮箱需要使用授权码，而非登录密码

测试配置：使用"通过发送测试邮件测试配置"验证设置是否正确

第五章：高级技巧与最佳实践

5.1 环境变量与参数化构建

Jenkins提供了丰富的环境变量，可以在构建脚本中使用：

BUILD_NUMBER：当前构建编号
JOB_NAME：任务名称
WORKSPACE：工作空间路径
BUILD_URL：构建详情页面URL

在Shell脚本中可以通过$变量名的方式引用这些环境变量，例如：

echo "构建编号：$BUILD_NUMBER"
echo "工作目录：$WORKSPACE"

5.2 凭证管理

为确保安全，敏感信息应使用Jenkins凭证管理：

进入"凭证" → "系统" → "全局凭证"
添加适合类型的凭证（用户名密码、SSH密钥、令牌等）
在项目配置中通过$变量名方式引用凭证

5.3 优化构建速度

使用镜像：为依赖包使用国内镜像源，加快下载速度
缓存策略：合理缓存node_modules等依赖目录
并行执行：如果有多阶段任务，尽量并行执行
选择高性能代理：对于大型项目，使用性能更好的Jenkins代理

5.4 故障排除技巧

查看控制台输出：这是最直接的调试方式，可以查看构建的详细日志
检查文件权限：确保Jenkins用户有足够的权限执行脚本和访问目录
验证环境变量：在构建开始时打印关键环境变量，确认配置正确
逐步调试：复杂脚本可以分步骤执行，逐步定位问题

第六章：自由风格项目的局限与Pipeline的进阶

6.1 自由风格项目的优势与不足

优势：

学习曲线平缓，适合初学者
可视化配置，直观易懂
灵活组合各种构建步骤

不足：

配置无法版本化，难以追溯变更历史
复杂流程配置起来较为繁琐
不支持复杂的条件判断和循环控制

6.2 何时考虑转向Pipeline

当你的构建流程满足以下条件时，建议考虑使用Jenkins Pipeline：

流程复杂：包含多个阶段、复杂条件判断或循环
需要版本控制：希望将构建配置像代码一样纳入版本管理
需要可追溯性：要求构建流程的每次变更都有记录
跨多个项目：需要在多个项目中复用相似的构建流程

6.3 Pipeline简介

Jenkins Pipeline使用代码（Jenkinsfile）来定义构建流程，支持两种语法：

声明式Pipeline：更简洁，适合大多数场景
脚本式Pipeline：更灵活，可以使用Groovy的全部功能

以下是一个简单的声明式Pipeline示例，对应我们前面创建的自由风格项目：

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git branch: 'main', 
                url: 'git@gitlab.example.com:your-group/your-frontend-project.git'
            }
        }
        stage('Build') {
            steps {
                sh 'npm install'
                sh 'npm run lint'
                sh 'npm test'
                sh 'npm run build'
            }
        }
        stage('Deploy') {
            steps {
                sh '''
                  TARGET_SERVER="user@webserver-ip"
                  PROJECT_NAME="frontend-$(date +%Y%m%d-%H%M%S)"
                  ssh $TARGET_SERVER "mkdir -p /var/www/$PROJECT_NAME"
                  scp -r dist/* $TARGET_SERVER:/var/www/$PROJECT_NAME/
                  ssh $TARGET_SERVER "cd /var/www && rm -f html && ln -s $PROJECT_NAME html"
                '''
            }
        }
    }
    post {
        always {
            emailext (
                subject: "构建结果: ${currentBuild.fullDisplayName}",
                body: "构建日志: ${env.BUILD_URL}console",
                to: "team@example.com"
            )
        }
    }
}