Jenkins基础教程（41）配置Jenkins 服务器之配置版本控制工具：代码脱单指南：让你的Jenkins服务器学会“撩”版本控制工具！-优快云博客

作为一名程序员，你是否经历过这样的深夜崩溃：本地代码跑得飞起，一到Jenkins就各种拉取失败？看着控制台满屏的红色错误，你恨不得把服务器从机房拽出来暴打一顿？别急，今天咱们就来给Jenkins做个“婚恋培训”，教它如何优雅地“追求”版本控制工具！

一、为什么要给Jenkins“说媒”？

想象一下这个场景：你的代码在本地活蹦乱跳，功能完美无缺。你满怀信心地提交到Git，然后……Jenkins构建失败了。不是权限问题就是密钥不对，就像个笨拙的直男试图约会却连人家地址都找不对。

版本控制工具对Jenkins来说，就是它的“另一半”。没有配置好这个关系，你的自动化流程就是个单身汉——啥事都得自己动手。

真实案例时间：
我团队里曾经有个新手小王，配置Jenkins时直接在构建脚本里写了Git命令。结果每次构建都要手动输入密码，最后他成功地把自己的工作变成了7x24小时客服——因为构建总是在他睡觉时失败！

所以，今天咱们要做的，就是给Jenkins配备一个“贴心女友”，让它能自动、无缝地从版本控制工具那里获取代码。准备好了吗？系好安全带，老司机要发车了！

二、版本控制界的“三国演义”

在开始配置前，咱们先快速了解一下Jenkins后宫里的“佳丽三千”：

Git - 时尚潮流小姐姐

特点：分布式、速度快、分支管理强大
适合：现代Web项目、开源项目、团队协作
缺点：学习曲线稍微陡峭

SVN - 稳重端庄大姐姐

特点：集中式、权限控制严格、概念简单
适合：传统企业、需要严格权限控制的场景
缺点：分支成本高、需要网络连接

Mercurial - 温婉可人小仙女

特点：分布式、命令简单、跨平台
适合：Python项目、跨平台团队
缺点：生态系统相对较小

今天咱们重点攻略最受欢迎的Git小姐姐，顺带撩一下SVN大姐姐。

三、环境准备：给你的Jenkins“梳妆打扮”

在开始追求之前，先确保你的Jenkins仪表堂堂：

Jenkins版本：2.346.3及以上（太老的版本就像穿着破洞衣服去约会——不合适）
必备插件：

Git Plugin（追Git小姐姐的必备用具）
Subversion Plugin（应对SVN大姐姐的利器）
SSH Plugin（搞定密钥认证的秘籍）

检查插件安装：

# 登录Jenkins后，访问
http://你的jenkins地址/pluginManager/installed

确认看到Git plugin和Subversion plugin都在列表中。

如果缺少某个插件，别慌：

进入【系统管理】->【插件管理】
在【可选插件】中搜索安装
安装完成后重启Jenkins

小贴士：安装插件时如果遇到网络问题，可以尝试更换清华镜像源，或者……默默祈祷然后重试。

四、配置Git：教你如何“追求”潮流小姐姐

Git是当今最流行的版本控制工具，就像班里最漂亮的女生，追求者众多。想要脱颖而出，你得有点真本事。

4.1 SSH密钥配置：拿到女神家的钥匙

使用SSH密钥就像拿到了Git小姐姐家的钥匙，可以自由进出，不用每次都要敲门（输入密码）。

生成SSH密钥对：

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

执行这个命令时，它会问你把钥匙放哪里，直接回车用默认位置就行。然后它会让你设置个密码，如果你懒得每次使用都输入，直接回车跳过。

查看公钥：

cat ~/.ssh/id_rsa.pub

你会看到一长串以ssh-rsa开头的内容，这就是你的公钥。

把公钥交给Git小姐姐：

GitHub场合：

点击头像 -> Settings -> SSH and GPG keys
New SSH key -> 粘贴公钥内容
取个有意义的名字，比如「Jenkins构建服务器」

GitLab场合：

点击头像 -> Preferences -> SSH Keys
粘贴公钥 -> Add key

在Jenkins里配置私钥：

进入【系统管理】->【Manage Credentials】
点击【全局】->【Add Credentials】
按照这样填写：

- Kind: SSH Username with private key
- Scope: Global
- Username: git（这个很重要！）
- Private Key: Enter directly -> 粘贴你的私钥内容

获取私钥：

cat ~/.ssh/id_rsa

复制显示的全部内容，包括-----BEGIN RSA PRIVATE KEY-----和-----END RSA PRIVATE KEY-----。

4.2 HTTP认证配置：备用的邀请函

如果SSH在公司网络被禁了（有些公司确实这么干），咱们还有HTTP这个备胎。

创建访问令牌：

GitHub：

Settings -> Developer settings -> Personal access tokens
Generate new token
勾选repo权限
生成后立即复制！它只显示一次

GitLab：

User Settings -> Access Tokens
设置名称、过期时间
勾选api、read_repository、write_repository等权限

在Jenkins中配置：

进入Credentials管理
添加Username with password类型凭证
用户名为：GitHub用户名（不是邮箱！）
密码为：刚才生成的访问令牌

4.3 实战：创建你的第一个Git任务

理论说再多不如动手试试，来，咱们创建一个实实在在的任务：

步骤1：新建任务

点击【新建任务】
输入任务名称：「my-first-git-job」
选择【Freestyle project】-> OK

步骤2：配置Git仓库
在源码管理部分：

选择【Git】
Repository URL: git@github.com:你的用户名/你的项目.git
或者HTTPS地址：https://github.com/你的用户名/你的项目.git

步骤3：选择凭证

Credentials: 选择刚才配置的SSH或HTTP凭证
Branches to build: */main 或 */master

步骤4：构建触发器

选择【Poll SCM】
日程表：H/5 * * * *（每5分钟检查一次更新）

步骤5：添加构建步骤

点击【增加构建步骤】->【Execute shell】
输入：

echo "开始构建！"
ls -la  # 查看拉取的文件
echo "当前分支："
git branch

步骤6：立即构建
点击【保存】然后【立即构建】，如果看到蓝色圆球，恭喜你！你已经成功让Jenkins追到了Git小姐姐！

排坑指南：
如果构建失败，检查以下几点：

仓库地址是否正确（特别是.git后缀）
凭证的用户名是否正确（SSH用git，HTTP用实际用户名）
网络连通性（有些公司需要配置代理）

五、配置SVN：如何搞定稳重端庄大姐姐

SVN就像传统大家庭里的大姐姐，规矩多但稳重可靠。追求她需要更多的礼仪和规范。

5.1 SVN凭证配置：准备正式的拜帖

创建SVN用户凭证：

进入Credentials管理
添加Username with password类型
输入SVN服务器的用户名密码
ID可以留空，Jenkins会自动生成

小技巧：如果你们的SVN使用LDAP认证，直接使用域账号密码就行。

5.2 高级SVN配置：应对挑剔的家长

有些SVN服务器配置比较严格，需要额外的配置：

忽略外部引用：
如果你的SVN仓库有很多externals，可能会导致构建缓慢。在Advanced选项中勾选【Ignore externals】可以解决这个问题。

指定版本：
在Revision中指定具体的版本号，可以让Jenkins每次都构建同一个版本，适合重现特定问题。

5.3 SVN实战：创建企业级任务

步骤1：基础配置

新建Freestyle项目：「my-svn-project」
源码管理选择【Subversion】

步骤2：仓库配置

Repository URL: http://svn.company.com/repos/your-project/trunk
选择刚才配置的SVN凭证

步骤3：高级选项

Repository depth: infinity（获取完整代码）
Ignore externals: 勾选（避免外部依赖问题）

步骤4：构建策略

可以选择定时构建：0 9,18 * * 1-5（工作日早晚各构建一次）

企业级小贴士：
对于大型SVN仓库，第一次获取可能会很慢。可以在服务器上预先做一次checkout，然后配置增量更新。

六、多分支流水线：成为时间管理大师

现代项目往往有多个分支，Jenkins需要同时管理多个“关系”。

6.1 多分支流水线配置

创建Multibranch Pipeline：

新建项目 -> Multibranch Pipeline
在Branch Sources中添加Git或SVN
配置扫描触发器，例如每小时扫描一次新分支

示例配置：

pipeline {
    agent any
    triggers {
        cron('H */4 * * *')
    }
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean compile'
            }
        }
    }
}

6.2 分支策略管理

main/master: 自动部署到生产环境
develop: 自动部署到测试环境
feature/*: 代码检查和单元测试
hotfix/*: 紧急修复通道

七、常见翻车现场及救援指南

即使老司机也难免翻车，这里总结几个常见问题和解决方案：

7.1 权限被拒（Public Key Denied）

症状：Jenkins报错Permission denied (publickey)

诊断：

# 在Jenkins服务器上测试连接
ssh -T git@github.com

解决方案：

检查私钥是否正确配置（包括首尾的---BEGIN---和---END---）
确保公钥已添加到Git服务
确认用户名是git而不是邮箱

7.2 找不到分支（Branch Not Found）

症状：Couldn't find any revision to build

解决方案：

检查分支名称（现在很多仓库用main而不是master）
确认该分支确实存在
检查凭证是否有该分支的读取权限

7.3 网络连接超时

症状：Connection timed out

解决方案：

检查网络连通性
配置代理服务器：

# 在Jenkins启动参数中添加
-Dhttp.proxyHost=proxy.company.com -Dhttp.proxyPort=8080

八、高级撩妹技巧：让关系更稳固

8.1 Webhook自动触发：心有灵犀一点通

配置Webhook后，代码一推送，Jenkins就自动构建，实现真正的心有灵犀。

GitHub Webhook配置：

仓库Settings -> Webhooks -> Add webhook
Payload URL: http://你的jenkins/github-webhook/
Content type: application/json
选择事件类型（推荐Just the push event）

Jenkins配置：
在任务中勾选【GitHub hook trigger for GITScm polling】

8.2 参数化构建：灵活的约会计划

让构建过程支持参数，就像给约会多个选择：

配置参数：

字符串参数：版本号、环境名称
选项参数：部署目标
布尔参数：是否跳过测试

九、实战完整示例：从零搭建企业级配置

下面是一个真实企业项目的完整配置示例：

9.1 项目信息

项目名：user-service
Git仓库：git@git.company.com:microservice/user-service.git
分支策略：git-flow

9.2 Jenkinsfile配置

pipeline {
    agent any
    parameters {
        choice(
            name: 'DEPLOY_ENV',
            choices: ['dev', 'test', 'staging'],
            description: '部署环境'
        )
        booleanParam(
            name: 'SKIP_TESTS', 
            defaultValue: false,
            description: '是否跳过测试'
        )
    }
    stages {
        stage('Checkout') {
            steps {
                git(
                    url: 'git@git.company.com:microservice/user-service.git',
                    credentialsId: 'jenkins-git-ssh',
                    branch: 'develop'
                )
            }
        }
        stage('Build') {
            steps {
                sh 'mvn clean compile -DskipTests=${SKIP_TESTS}'
            }
        }
        stage('Test') {
            when {
                expression { return params.SKIP_TESTS == false }
            }
            steps {
                sh 'mvn test'
            }
        }
        stage('Deploy') {
            steps {
                echo "部署到 ${DEPLOY_ENV} 环境"
                sh "mvn deploy -Denvironment=${DEPLOY_ENV}"
            }
        }
    }
    post {
        always {
            emailevent (
                subject: '构建完成: ${JOB_NAME}',
                body: '构建详情: ${BUILD_URL}'
            )
        }
        failure {
            slackSend channel: '#build-alerts', message: '构建失败: ${JOB_NAME}'
        }
    }
}