CI，Continuous Integration，持续集成，是软件开发过程中一个非常重要的环节，在互联网敏捷开发的过程中，持续集成通常用来进行日常编译和自动化测试，来保证及时发现提交的问题，避免影响项目进度。 通常持续集成的过程包括：
持续集成（Continuous integration，简称CI）指的是，频繁地（一天多次）将代码集成到主干。
目前的现状,开发者在提交代码后还需要去构建镜像,上传镜像到镜像仓库,频繁的修改就需要频繁的构建。
最近的一两年都在业余时间逼自己学习，对某个领域，项目进行高强度，系统地学习，并输出一定数量的文章。使用这个思路我写出了 《ThingsBoard系列教程》 与 《Node-RED系列教程》，这两个都是开源项目，我花了很多业余时间研究它们，更是完整地把它们的官网文档看了几遍，虽然这个两个东西在我日常工作中完全没用到。后来我又学习了GitLab CI/CD，一开始不知道怎么学，因为在学的过程中，总是需要一些基础知识，比如某个名词不动，比如某个组件有哪几部分组成。相互之间是怎么连接的，这些在开始之初都困扰着我，但随着我看的文档足够多。这些问题都逐渐理解，明白。如果说ThingsBoard与NodeRED还算与前端有些关系，那GitLab CI/CD就离前端有些远了。为什么我能够在不属于自己的领域创造这样的一个成就？我想除了我不懈地追求答案，还和我学习一项技能的一些方法。这一篇文章我就稍微总结一下，我学习一项技能的方法和技巧。
时值 GitLab 14 大版本更新，官方对于这个版本给出了非常高的评价，让我非常好奇，所以为了探究新版本到底有哪些变化，我对 GitLab 社区版、极狐版做了试用对比。
将项目代码整体打包到新环境(新电脑), 在idea/pycharm下载好git相关插件并打开项目之后, 通过git拉取代码失败(gitlab/git/gtee)
随着前端工程的发展，组件化的思想早已深入人心；现代的前端框架React/Vue等，都是围绕组件设计；组件化的开发模式，大大提高了开发效率；设计和开发高质量高复用性的公共组件，可以更好地保持产品迭代的高效和稳定。
软件开发最大的麻烦事之一，就是环境配置。用户计算机的环境不相同，可能导致软件无法运行。
作为DevOps交付流水线的开发者，为支持CI/CD中各项任务的自动化，都需要依赖多种包管理工具来下载各种相关的工具，比如针对产生最终交付件的构建过程，就需要在构建流程的第一步，自动地把相关工具，如Curl、wget、Maven、Gradle、npm等等，下载到CI服务器。这些工具的下载，通常都需要依靠对应的公网服务器和包管理工具来支持。而这样通过公网来下载工具，有时会遇到稳定性的问题，也就是所谓的环境问题，导致工具下载失败，进而导致构建任务的失败。因此，我们需要引入新的技术来克服这些问题，保证工具包下载的稳定和可靠。
针对生产环境发布新版本后有bug需要紧急修复的情况，协作流程思路：新建对应的hotfix补丁分支，相关开发人员基于hotfix分支进行bug修复，修复完毕验证无误后，同样通过Merge Request合并至主仓库，然后由hotfix分支构建重新发布至生产。
做为一个略微看过nodejs语法，但又不懂nodejs的攻城狮，搭建hexo环境很是麻烦，要考虑到翻墙、版本兼容等问题。于是乎，博主每换一个电脑，为了能继续发博客，都需要在新电脑上花一天时间重新搞一下 hexo 环境，楼主感觉还是有简洁的方案来实现我一提交代码就可以自动发布博客，不需要再手动操作一波，这样岂不美哉。so，也就有了今天的经历，代码可以持续集成，博客也可以。楼主的解决方案是使用gitlab与gitlab-runner实现博客部署的持续集成，效果真的不要太好。
当前版本控制系统（Version Control System，VCS）有集中化版本版本控制系统（Centralized Version Control System，简称 CVCS）和分布式版本控制系统（Distributed Version Control System，简称 DVCS）。 集中化版本控制系统的代表是SVN，分布式版本控制系统的代表是GIT。
GitLab一个开源的git仓库管理平台，方便团队协作开发、管理。在GitLab上可以实现完整的CI（持续集成）、CD（持续发布）流程。而且还提供了免费使用的Plan，以及免费的可以独立部署的社区版本。
本文将介绍在CentOS已部署LNMP环境下,使用Docker安装GitLab,并配置SSL证书HTTPS访问.
GitLab Runner(为了叙述方便，以下简称Runner) 是与GitLab的CI/CD执行环境，是GitLab的一个工具包。 简单来说吧， Runner就是自动化部署任务的执行环境。你编写的一条自动化部署的流水线，包含了安装，测试，部署三个任务，这三个任务在哪个环境下执行那，就是在Runner中。没有Runner，GitLab CI/CD就没办法远行。
GitLab擅长源代码管理，Rainbond擅长应用自动化管理，整合Gitlab和Rainbond就能各取所长，本文详细讲述如何整合Gitlab和Rainbond，并通过整合实现一体化开发环境。
用下面的命令启动一个默认配置的Gitlab。如果我们只在本机测试使用的话，将hostname替换为localhost。如果需要让外部系统也能访问的话使用外网IP地址。
GitLab 社区版：gitlab-ce-12.8.7-ce.0.el6.x86_64.rpm，可从 清华大学开源软件镜像站 下载
Before setting everything else, configure a new environment variable $GITLAB_HOME pointing to the directory where the configuration, logs, and data files will reside. Ensure that the directory exists and appropriate permission have been granted.
Rainbond作为应用运行环境，Gitlab可以运行在Rainbond之上，为了便于Gitlab安装，我们制作了Gitlab安装包放到了Rainbond的应用市场，实现Gitlab的一键安装。
网上有很多安装gitlab的方法，这里推荐使用docker安装，真的超级超级方便。 这里有一篇文章 docker安装配置gitlab详细过程 https://www.cnblogs.com/zuxing/articles/9329152.html 这里就不细说了。毕竟重点不是说怎么安装gitlab哈哈哈。
想要成为一名架构师，一定要有从无到有搭建环境的能力，这是作为架构师的基础技能，而gitLab服务器的搭建一定又是重中之重。
本文来告诉大家如何使用 dotnetCampus.GitLabMergeRequestCreator 工具，命令行创建 GitLab 合并请求 Merge Requests 的方法
最近需要修改一个很重要的项目源码，但是这个源码的代码仓库权限又不能给我们，只给了一份拷贝的版本，为了能够更好地对这份代码进行代码版本管理，我决定在本地搭建一个 Gitlab 仓库，来和其他同事进行协同开发。
因为单位机房搬迁，涉及到之前为运维开发搭建的GitLab环境也需要做迁移。旧环境中安装的时候很顺畅基本没有碰见什么问题(参考：http://blog.csdn.net/bisal/article/details/52515327)，但这次新环境的安装着实费了一些功夫，碰见了一些棘手的问题，记录于此，对碰见这些问题的朋友们有所帮助。
配置API token, 需要登陆gitlab，给一个developer角色的账号，在系统设置中找到access token, 获取token。 然后在Jenkins中配置Gitlab API Toekn的凭证。
Gitlab的持续集成功能依赖于Gitlab Runner组件完成，gitlab runner作为Gitlab这个中控机的执行者，按照代码仓库里面.gitlab-ci.yaml文件里面预定义的任务job按照指定的顺序或并发的执行完成系列的编译、测试、部署等操作，也就是说只要按照.gitlab-ci.yaml的配置格式[1]将写好的.gitlab-ci.yml文件放在代码仓库内，待下一次代码提交commit的时候就会自动的触发仓库绑定的Gitlab Runner去按照.gitlab-ci.yml里面配置的指定的执行。
通过前面的分享，我已经在自己的环境中安装了gitlab-runner和jenkins，我以前用的是脚本全自动部署，所有操作都是由shell执行器完成，并没有涉及docker执行器。然后今天我就分享下，对于gitlab-runner执行器的一点认识。
在上一篇文章中，我们介绍了如何使用Docker搭建自己的GitLab代码托管平台。
以前代码更新之后，我们需要手动将代码拉到测试服务器上，运行验收通过之后，再在生产环境重新弄一遍，一两个服务还算轻松，如果涉及到的服务很多的话，每一个服务都需要这样来几遍，这是一个很头疼了，为了解决这个问题，我们引入了比较简单易懂的自动化部署工具，这也是gitlab自带的CI工具gitlab-runner，该工具解决了多环境多服务手动部署繁琐问题，用自动化脚本代替人工部署，我们不需要手动去部署单个服务，可以机械化的执行我们的部署过程。那么一个项目如何配置gitlab CI来实现自动部署呢，主要分两步(前提条件时已经又gitlab-runner服务了)：
在公司搭建内部 GitLab 平台后，前端活动项目从 SVN 迁移到 GitLab。本文介绍如何基于 GitLab CI/CD 实现自动化构建及发布。
GitLab CI/CD 是一个内置在 GitLab 中的工具，用于通过持续方法进行软件开发：
如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。
来源丨 www.cnblogs.com/cjsblog/p/12256843.html
本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 署名 4.0 国际 (CC BY 4.0)
如之前的文章安装 CoreDNS、GitLab、Jenkins 容器 所述熟悉了基本的容器安装之后就可以配置 Jenkins pipeline 构建基于 maven 的 Java 项目了。
本文关键字：云IDE。docker as cloud ide，在群晖上安装docker gitlab,gitlab ci for docker
在持续集成之Gitlab环境搭建里面详细的介绍了Gitlab环境的搭建。本次就持续更新Gitlab与Jenkins的整合。登录到Gitlab后，创建project名为testing的仓库,Visibility Level设置为Private，见创建后的信息，如下截图所示：
也就是说，使用GitLab进行Code Review就是在分支合并环节发起Merge Request，然后Code Review完成后将代码合并到目标分支。
大家好，这里是开源技术实验室，我是TopJohn，互联网码农，开源爱好者，有兴趣的小伙伴，可以关注微信公众号：《开源技术实验室》，有更多文章发布。
安装Docker curl -sSL https://get.docker.com/ | sh 安装Gitlab sudo docker run --detach \ --hostname gitlab.example.com \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab \ --restart always \ --volume /srv/gitlab/config:/etc/
您可以通过重复register命令在同一台主机上注册多个运行器，每个运行器配置不同。
PS：可能有的插件安装不了，不要慌老铁，进入到jenkins的管理页面会提示你更新jenkins更新下，然后插件又可以自动下载安装完毕了。
（1）生成密钥 本地服务器在 ~/.ssh 目录下可以找到 id_rsa.pub，里面就是公钥
如下图所示，开发者将代码提交到GitLab后，可以触发CI脚本在GitLab Runner上执行，通过编写CI脚本我们可以完成很多使用的功能：编译、构建、生成docker镜像、推送到私有仓库等：
在甲方做安全的同学可能会有一项代码审计的工作，通常需要从gitlab把代码拉取下来，然后使用代码审计工具进行扫描，然后对结果进行人工确认；
开发团队在开发环境中完成软件开发，单元测试，测试通过，提交到代码版本管理库。运维团队把应用部署到测试环境，供QA团队测试，测试通过后部署生产环境。QA 团队 进行测试，测试通过后通知部署人员发布到生产环境。
领取专属 10元无门槛券
手把手带您无忧上云
