*系列汇总*
文章汇总地址如右：Jenkins入门教程。
如果相中哪个，点击进去便是。希望正在读这段话的你能够在这个小系列中获得自信以及喜悦！
本文整理自网上飞翔大神分享的文章。
1，闲言碎语。
承接上一篇文档以及在上篇所配置好的环境，继续往前走，模拟开发提交代码之后，Jenkins自动构建的试验。
之前从来没有做过自动构建的事情，有时候听着别人说如何如何，开发提交之后就构建了，好像很不一般。
自己知道是如何实现的，但是总觉得好像有局限，就没有前去涉猎，但是今天根据教程看了之后，发现有些事情呀，或者有些偏见呀，都是来自于一些小的，基础的不能在基础的东西。因为你不懂某个小基础，那么，可能蝴蝶效应的，后续很多东西你也就无从知起。
好了，进入正题。
这里主要展示以下内容。
需要准备的：
现在进入正题。因为试验已经根据飞翔文档做过一遍了，所以现在整理的话，就不再看文档了，根据自己的记忆，来完成整个的配置。
2，先在gitlab上操作。
1，在gitlab创建测试项目。
关于gitlab的安装这里就不展示了，不熟悉的小伙伴可以出门左转参考我发布过的gitlab的文章。（点击转到gitlab部署安装）现在我们直接来到Windows的git客户端。
Administrator@liqilong MINGW64 ~/Desktop/gittest $ git clone git@192.168.106.70:linux/test.git Cloning into 'test'... warning: You appear to have cloned an empty repository. Administrator@liqilong MINGW64 ~/Desktop/gittest $ cd test Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master) $ echo "this is master branch." > readme Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master) $ cat readme this is master branch. Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master) $ git add readme Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master) $ git commit -m 'add readme' [master (root-commit) bf79505] add readme 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 readme Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master) $ git push -u origin master Counting objects: 3, done. Writing objects: 100% (3/3), 204 bytes | 204.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) To 192.168.106.70:linux/test.git * [new branch] master -> master Branch 'master' set up to track remote branch 'master' from 'origin'.
然后去gitlab中就能看到刚才创建的项目已经有内容了。
接着再来创建一个分支作为开发分支。再来一波操作。
Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master) $ git branch dev Administrator@liqilong MINGW64 ~/Desktop/gittest/test (master) $ git checkout dev Switched to branch 'dev' Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ ls readme Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ echo "this is dev branch" > readme Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ cat readme this is dev branch Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ git commit -a -m 'add dev' warning: LF will be replaced by CRLF in readme. The file will have its original line endings in your working directory. [dev 8419ae8] add dev 1 file changed, 1 insertion(+), 1 deletion(-) Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ git push origin dev Counting objects: 3, done. Writing objects: 100% (3/3), 248 bytes | 248.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: remote: To create a merge request for dev, visit: remote: http://192.168.106.70/linux/test/merge_requests/new?merge_request%5Bsource_branch%5D=dev remote: To 192.168.106.70:linux/test.git * [new branch] dev -> dev
然后去gitlab就能看到dev分支以及对应内容了。
3，将Jenkins的公钥放入gitlab中，测试是否可以进行拉取代码。
假定我们的项目目录是宿主机的/usr/local/test目录。
[root@localhost test]$cd /usr/local/ [root@localhost test]$git clone -b dev git@192.168.106.70:linux/test.git Cloning into 'test'... remote: Counting objects: 9, done. remote: Compressing objects: 100% (3/3), done. remote: Total 9 (delta 0), reused 0 (delta 0) Receiving objects: 100% (9/9), done. [root@localhost test]$ls test [root@localhost test]$cd test/ [root@localhost test]$ls readme [root@localhost test]$cat readme this is dev branch 说明： -b 是根据分支进行拉取。
4，ok，现在我们去创建一个项目进行测试。
来到Jenkins的配置界面。
1，先添加这样一个ssh server。
进入系统管理—》系统设置。
如果测试中报错： jenkins.plugins.publish_over.BapPublisherException: Failed to connect and initialize SSH connection. Message: [Failed to change to remote directory [/usr/local/test]]
看信息得知是没有这个目录，去服务器创建一下就好了。
然后新建项目，创建一个自由风格的名为test的项目，分支填写成dev，从而在构建的时候直接默认为dev分支。
接着配置构建触发器。
在构建中添加ssh server的动作，具体操作如下图：
暂时这样一个简答的项目就创建完成了。
简单总结配置：
5，将刚才的Jenkins api添加到gitlab中。
说明：
那么现在就在gitlab这里先测试下效果，看看点击这里之后，Jenkins是否会自动构建。注意，我们现在的项目可是刚创建好，现在先去跑一下看看效果如何。
这里是我们的第一次构建，如果你跟着做的，但是构建失败或者异常，那么有以下思路可供参考：
6，试验。
那么接下来，我们一层一层剥离，先看在gitlab中手动一下看看是否能联动Jenkins的构建。
方法很简单，在前边配置好的webhook当中点击Push Events.
点击之后，我们去看下Jenkins那边是什么效果。
哎呦我去，报错了！！
看到403的错误应该是刚刚添加的URL访问出问题啦。而，前人存在的意义正在于，把这些小坑填平助我们直驱成功。
现在去到Jenkins方。点击系统设置—》全局安全配置—》取消“防止跨站点请求伪造”—》配置授权“授权策略”中的“安全矩阵”。
接着：
配置完之后保存，然后再重复刚才在gitlab当中的动作。
看到了返回值至少已经是200了。如下图：
接着去Jenkins中看看。
再看下构建信息：
完美。如果已经到了这步，那么接下来你就可以安心于开发了，从你开发中，无论开发了什么代码，只要一进行提交，那么就会触发Jenkins的构建，新代码也就自动跑到远程目标服务器啦。
接下来先模拟一下开发与提交：
Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ ls readme Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ echo "Test push code builds automatically" >> readme Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ cat readme this is dev branch Test push code builds automatically Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ git commit -a -m "Test push code builds automatically" warning: LF will be replaced by CRLF in readme. The file will have its original line endings in your working directory. [dev 0cd5af4] Test push code builds automatically 1 file changed, 1 insertion(+) Administrator@liqilong MINGW64 ~/Desktop/gittest/test (dev) $ git push origin dev Counting objects: 3, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 309 bytes | 309.00 KiB/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: remote: To create a merge request for dev, visit: remote: http://192.168.106.70/linux/test/merge_requests/new?merge_request%5Bsource_branch%5D=dev remote: To 192.168.106.70:linux/test.git 8419ae8..0cd5af4 dev -> dev
now，去看下Jenkins是否执行了构建并把新代码推到了远程服务器。
然后看代码是否是新的。
此处模拟的算是一个类似php或者静态网站开发的一系列自动化，那么，套用这个思路，基本上对于java项目，nodejs项目，以及其他项目，都是可以通过这种方式来进行配置构建的。
以上的试验流程，是依据原文进行了一次疏通与整理，并没有再往深入的探索以及应用，因为在我们公司里边，并没有任何一个项目，是使用了自动构建的这种方式的，当然了，每家有每家的情况，要能够结合实际工作情况，来进行分析判断。
7，补充内容，分支的探索。
昨天收到一个同学的求助，说自己公司的情况正是如此，测试预发线上三个环境全部都在一个Jenkins中，然后测试以及预发的项目都做成了自动构建的，现在的问题是，在测试提交代码，会发现，测试以及预发的这个项目都构建起来了。那么问题来了，如何实现，提交对应的环境的代码，就只有对应环境的项目部署？
首先，听完这段话，我想说，首先三个环境放在一起，不合理，测试可以自动构建，预发，不应该自动构建了，最后他的回答是，这些功能是之前的运维人员配置的，现在也没有太多话语权，无法决定大建筑上的东东。
唯有提升自己的技术，才是最真的王道！
那么好，现在就来说说这个自动构建过程中如何让项目区分开来。当然，可能像这样测试预发放在一起，又同时开启了自动构建的情况，并不常见，但是，经过对接下来这个知识点的了解学习，可以让我们掌握，如何在配置自动构建的时候，灵活的控制分支问题。
其实，玄机就在Jenkins项目配置当中webhook处的高级里边的内容，下图是展开的高级的样子：
这个地方Jenkins默认的选择的是接受所有分支提交的触发，也就是，无论你提交了什么分支，那么都会触发此项目的构建。
现在，假如我们开发的分支都是dev分支，那么可以如下图设置：
这样配置之后，即代表此项目只在当dev分支提交会触发构建，其他分支提交则不会触发构建。
当然这个地方可以使用通配符进行扩展性定义：
- *.dev ： 表示以dev结尾的分支提交都会触发构建。
- dev.* ： 表示以dev开头的分支提交都会触发构建。
- *.dev.* ： 表示包含dev的分支提交都会触发构建。
嗯，这个知识点就分享到这里，如果有一些其他的个性化需求，请根据这些现有的功能，发挥自己的脑洞，灵活运用。
