阅读目录：
install configue gitlab-ci-multi-runner
restore nuget packages
bulid .sln
run unit tests
configue .gitlab-ci.yml
configue build status badge image
CI 精华文章：
<a href="http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html">持续集成是什么？</a>
<a href="http://www.cnblogs.com/davenkin/archive/2012/02/25/continuous-integration-from-martin-fowler.html">重温大师经典：Martin Fowler 的持续集成</a>
Gitlab 部署 CI 相关资料：
<a href="https://ruby-china.org/topics/28726">配置 gitlab-ci 进行持续集成</a>
<a href="http://answ.me/post/build-docker-images-automatically-via-gitlab-ci/">使用 GitLab-CI 来自动创建 Docker 镜像</a>
<a href="https://www.zybuluo.com/bornkiller/note/314902">基于 gitlab 搭建 CI 环境</a>
<a href="http://archiechen.github.io/blog/2013/01/12/shi-yong-gitlab-he-gitlab_ci-jin-xing-chi-xu-ji-cheng/">使用 gitlab 和 gitlab_ci 进行持续集成</a>
持续集成（Continuous integration - CI）的作用：代码在提交到资源库之前，进行构建、自动化测试和发布等等，我们每天需要提交大量的代码，持续集成可以有效的帮助我们发现代码中的 Bug，并且减少一些反复的工作等等，使团队更加有效的开发协作。
Gitlab 在 8.0 以上版本集成了 CI，所以我们不需要另外配置一个 gitlab-ci-server 服务器，为我们部署减少了很多的工作，点个赞！
先吐槽下，Gitlab 部署 CI 我大概花了一周的时间，但也只是进行了一点点，最重要的三点：<code>nuget restore</code>, <code>bulid *.sln</code>和<code>run unit tests</code>现在基本上是可以了，在部署的过程中，深感到问题分享的重要性，遇到的大量问题，Google 基本上搜不到，中文相关资料也就上面的几篇文章，但看过之后发现都是简简单单的介绍而已，并没有记录详细的部署过程，所以，我基本上都是看的 Gitlab 官方帮助文档，但 Gitlab 的更新很频繁，所以有些帮助文档都没进行更新，避免不了踩进一些坑，那怎么办呢？解决方式就是不断的进行尝试，比如我配置<code>.gitlab-ci.yml</code>文件的时候，就不断的进行<code>code commit</code>测试（一百多个提交）：
并且有先见之明的把问题解决过程，都用 Issue 进行记录了：
下面就从上面这几个 Issue 进行展开，把每个问题和解决过程都分享出来，希望可以帮助到遇到相同问题的园友。
GitLab 部署 CI 的第一步就是安装 gitlab-ci-multi-runner，你可以把它理解为：跑 CI 的服务。
在 Gitlab 项目中打开 Settings > Runners，找到<code>URL</code>和<code>token</code>，等会安装的时候需要配置。
安装配置步骤：
上面<code>executor: shell</code>是默认配置，意思是本地执行，也可以使用<code>ssh</code>和<code>docker</code>，不过需要增加一些远端链接配置。
停止，运行和验证命令：
如果运行<code>C:\Multi-Runner>gitlab-ci-multi-runner-windows-amd64.exe start</code>出现错误，则需要将<code>gitlab-ci-multi-runner-windows-amd64.exe</code>拷贝一份，重命名为<code>gitlab-ci-multi-runner.exe</code>。
另外， Gitlab 项目 Settings > Project Settings Features > Builds 选项需要打勾。
gitlab-ci-multi-runner 安装配置完之后，我们就可以在 Gitlab 项目 Settings > Runners 中，看到 Runners 的信息了。
这次任务：使用 CI， nuget 还原解决方案中的程序包。
添加好<code>.gitlab-ci.yml</code>文件配置后，我们就可以在项目中的 Builds，看到提交后的构建工作了，随便在 Gitlab 项目中添加一个解决方案，然后再添加一个类库项目，并且使用 nuget 安装一个程序包，最后使用 git 提交到 Gitlab 中，就可以看到 Builds 的过程和结果了，首次提交结果如下：
这个问题搞了我很久，因为错误信息乱码了，根本找不到相关的解决方案，后来无意间搜到 Gitlab 中的一个 Issue，里面提到了一个<code>gitlab-ci-multi-runner --debug run</code>命令，意思是调试运行 CI，这样我们就可以看到详细的错误信息了，debug 的错误信息比较多，并且完全看不懂，不过我们可以通过 Builds 看到简洁的错误日志：
解决方式：<code>C:\Multi-Runner\config.toml</code>文件添加<code>shell = 'powershell'</code>节点，添加在<code>[[runners]]</code>节点后。
解决完这个问题之后，去研究了下<code>.gitlab-ci.yml</code>中的<code>nuget restore</code>配置（Google 搜的，太坑），将<code>.gitlab-ci.yml</code>文件修改如下：
<code>commit</code>提交测试，出现下面的错误信息：
从错误信息中可以看到，没有识别<code>restore</code>命令，啥意思？这个问题又搞了我好久，Google <code>Unexpected token 'restore' in expression or statement.</code> 关键字，毛都搜不到，没办法，后来只能更换关键字搜，但搜到的信息凤毛麟角，后来参考搜来的资料，将<code>.gitlab-ci.yml</code>改为：
或
<code>%VS140COMNTOOLS%\vsvars32.bat</code> 是什么鬼？不太清楚，毫无疑问，又出现了错误，信息如下：
也是毫无头绪的错误，这么办呢？后来想想<code>nuget restore</code>始终不成功，能不能换个命令呢？突然想到了 ASP.NET 5，还原程序包使用的是<code>dnu restore</code>命令，那就尝试下吧，将解决方案中的项目删掉，然后添加 ASP.NET 5 项目，<code>.gitlab-ci.yml</code>改为：
哇塞，这次终于成功了（突然有种想哭的冲动），日志信息：
虽然 ASP.NET 5 还原程序包成功了，但依旧解决不了问题啊，因为必须得解决<code>nuget restore</code>的问题，因为很多项目都没用 ASP.NET 5，怎么办呢？又回到了出发点，问题能磨死人啊，过程就不叙述了，后来无意间将<code>.gitlab-ci.yml</code>改为：
仔细看看和上面的配置有什么不同，我把<code>'"</code>去掉了，<code>commit</code>代码测试，出现了下面和一开始不一样的错误（有戏了）：
根据上面的错误日志，可以看到，就是目录中的<code>x86</code>问题，然后我把目录改为<code>C:\Program Files\NuGet\nuget.exe</code>之后（<code>nuget.exe</code>拷贝到相应目录下），还是有问题，然后就直接放在<code>C</code>盘目录下，终于<code>build</code>成功（眼泪夺眶而出）。
<code>.gitlab-ci.yml</code>配置：
<code>build</code>成功日志：
看似简单的结果，但过程真是太扯蛋了，如果我当时看到类似这篇博文分享，也不至于如此，还没完，继续。。。
这次任务：使用 CI， build 生成解决方案中的项目。
生成解决方案的问题解决过程相对简单些，不过上面漏掉了一处，这边再补充下，<code>.gitlab-ci.yml</code>配置：
错误日志：
<code>.gitlab-ci.yml</code>配置改为：
然后看到了详细错误（又有戏了）：
<code>error MSB1009: Project file does not exist.</code>这个错误就很清晰了，项目文件找不到，也就是没有找到<code>CNBlogsCI-Sample.sln</code>，怎么会呢？重新查看了 Gitlab 中的项目文件目录，<code>CNBlogsCI-Sample.sln</code>在根目录下的<code>src</code>目录下，重新修改下<code>.gitlab-ci.yml</code>配置：
<code>build</code>成功，日志详情：
这次任务：使用 CI， run 跑解决方案中的单元测试，可以成为自动化测试。
这次基本上没有什么问题解决过程，因为 Google 完全搜不到相关资料，所以，我最后是按照我的想法实现的，xUnit 除了用 VS2015 进行跑单元测试外，我们还可以用命令行的方式，打开 <code>cmd</code> 输入：<code>C:\xunit.runner.console\tools\xunit.console.exe "src\ClassLibrary2\bin\debug\ClassLibrary2.dll"</code>，结果如下：
好，既然命令行可以跑单元测试，那么我们就可以在<code>.gitlab-ci.yml</code>中添加脚本配置，如下：
xUnit 单元测试不通过日志：
xUnit 单元测试通过日志：
基本上实现了我们想要的效果，但这种实现方式有两个不好的地方：
需要将单元测试的 <code>*.dll</code> 文件上传到 git 资源库。
每增加一个单元测试项目，就必须在<code>.gitlab-ci.yml</code>中添加一段脚本。
我个人觉得 CI 中的自动化测试，肯定不是像我这样搞的，但实在找不到相关资料，如果大家知悉，还请告知，感谢～
另外，如果是 ASP.NET 5 项目，进行自动化测试配置，会非常简单，配置如下：
其他示例：
<a href="http://stackoverflow.com/questions/32964953/gitlab-ci-and-msbuild-with-tests">http://stackoverflow.com/questions/32964953/gitlab-ci-and-msbuild-with-tests</a>
<a href="https://github.com/CWISoftware/accounts/blob/master/.gitlab-ci.yml">https://github.com/CWISoftware/accounts/blob/master/.gitlab-ci.yml</a>
<a href="http://www.timtilberg.com/tag/gitlab/">http://www.timtilberg.com/tag/gitlab/</a>
<a href="http://doc.gitlab.com/ee/ci/yaml/README.html#stages">http://doc.gitlab.com/ee/ci/yaml/README.html#stages</a>
<a href="https://github.com/travis-ci/travis-ci/issues/5210">https://github.com/travis-ci/travis-ci/issues/5210</a>
<code>.gitlab-ci.yml</code>中的配置说明，上面的官方资料介绍的非常详细，下面我再简单介绍下，就用我这次部署 CI 完善后的<code>.gitlab-ci.yml</code>配置：
<code>stage</code>翻译为阶段的意思，在构建的过程中，必须要有一个先后顺序，最上面的<code>stages</code>配置意思是，先构建阶段为<code>build</code>的<code>job</code>，然后再构建阶段为<code>test</code>的<code>job</code>，下面<code>build_job</code>和<code>test_job</code>都是<code>job</code>，如果不配置<code>stages</code>，默认为：
<code>before_script</code>的意思是，执行在所有的<code>job</code>之前的脚本，比如构建<code>build_job</code>和<code>test_job</code>都先执行<code>before_script</code>，<code>build_job</code>和<code>test_job</code>中的<code>stage</code>配置，意思是此<code>job</code>属于哪个<code>stage</code>，这个<code>stage</code>就是最上面的<code>stages</code>配置，除了默认的<code>build</code>,<code>test</code>和<code>deploy</code>，你也可以添加自定义的<code>stage</code>，另外，如果<code>job</code>不添加<code>stage</code>配置，默认配置为<code>test</code>，比如上面的<code>test_job</code>，就可以省略<code>stage: test</code>配置。
另外，<code>job</code>还有一个<code>when: on_failure/on_success /always</code>配置，如果我们对<code>job</code>进行了<code>stage</code>配置，默认都会是<code>when: on_success</code>：
<code>only - master</code>的意思是，只有`<code>master</code>分支才会进行构建，<code>script</code>的意思很明了，就是要执行的脚本命名。
构建状态徽章，就是我们平常在 Github 项目中看到构建图标，有<code>pass</code>和<code>failing</code>等等。
复制上面的代码，然后添加在<code>README.md</code>文件中：
这样在<code>commit``bulid</code>的时候，就会动态的显示<code>bulid</code>的过程和结果，并且是图片显示。
Gitlab 部署好 CI 之后，我们会发现，在项目中随处可见这样的图标：
这篇博文没有什么阅读价值，因为都是零零碎碎的问题和解决纪录，没有什么可读性，如果你能阅读到这，我真的会很感动。
分享是有价值的一件事，如果园友在遇到相同问题的时候，可以 Google 到这篇博文，那写这篇博文也就值了。
本文转自田园里的蟋蟀博客园博客，原文链接：http://www.cnblogs.com/xishuai/p/gitlab-ci.html，如需转载请自行联系原作者