上次分享了gitlab+jenkins实现CICD，前提我们需要安装一个jenkins。其实高版本的gitlab已经具备CICD功能，笔者使用的版本是：GitLab 社区版 11.4.10
作为一个个人开发者，在业余时间也会想着开发一些个人的好玩的项目，去开发一些效率工具，开发一些自己喜欢的程序，在这个前提下，很多人购买了自己的服务器，作为一个前端开发，在最开始的时候对服务器相对会比较陌生，如果接触不多，在部署自己的项目过程中也会有许许多多的不便，我们也可以为自己搭建一套自动化部署，能够让我们在开发个人项目的时候享受同样的便捷。
也就是在去年，我们在密集开发了将近 1 年的 node 项目后，一个 egg 项目中包含了 500 多个接口，代码量也变得非常大。所以我们准备将服务拆分，然后将一些服务封装成 npm 包。因为这些 npm 包中包含业务逻辑，所以必须自建私有 npm 完成这个事情。所以自建 npm 就提上日程。
1）在上图红圈2部分设置需要跟踪变化的分支，根据上面的选项配置，可以是允许全部分支的变化触发构建，也可以设置只是具体的某些分支触发，这里示例是允许master分支上的变化触发构建。
不知道为什么，现在什么技术都想学，因为我觉得我遇到了技术的壁垒，大的项目接触不到，做的项目一个字辣*。所以，整个人心浮气躁，我已经得通过每天的骑行和长跑缓解这种浮躁了。一个周末，我再次宅在了家里，学习了一下CICD。
PS：最后总结下，建议jenkins不要使用容器安装，我用容器安装入了至少十几个坑，对了解命令还是有好处的。我总结几点
本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 署名 4.0 国际 (CC BY 4.0)
如果直接渲染1W行列表，不出意外你的页面就要卡了，比较常见的优化方案就是虚拟滚动，就是只渲染你能看到的视窗中的几十行，然后通过监听滚动来更新这几十个dom
Helm 的安装请自行搜索后安装 helm3 repo add gitlab https://charts.gitlab.io helm3 search repo -l gitlab/gitlab-runner
以前代码更新之后，我们需要手动将代码拉到测试服务器上，运行验收通过之后，再在生产环境重新弄一遍，一两个服务还算轻松，如果涉及到的服务很多的话，每一个服务都需要这样来几遍，这是一个很头疼了，为了解决这个问题，我们引入了比较简单易懂的自动化部署工具，这也是gitlab自带的CI工具gitlab-runner，该工具解决了多环境多服务手动部署繁琐问题，用自动化脚本代替人工部署，我们不需要手动去部署单个服务，可以机械化的执行我们的部署过程。那么一个项目如何配置gitlab CI来实现自动部署呢，主要分两步(前提条件时已经又gitlab-runner服务了)：
上一个轮回，我花了三篇文章的时间着重向大家介绍了在条件有限的情况下，如何优雅地进行前端发版和迭代。庆七一，热烈庆祝中国香港回归，人民生活水平越来越好，昨天上午我自掏腰包买了台服务器，决定由冷兵器脚本编程部署时代进入热武器CICD 时代。
由于目前公司使用的gitlab，大部分项目使用的CICD是gitlab的CICD，少部分用的是jenkins，使用了gitlab-ci一段时间后感觉还不错，因此总结一下
https://juejin.cn/post/6950280074876682276
CI/CD 是持续集成(Continuous Integration)和持续部署(Continuous Delivery/Deployment)的缩写。
截止昨天已经将应用容器化并部署到k8s平台上，但是每次都要手动部署肯定不现实，所以有一个可自动部署的平台或功能是很重要的，这样就能实现随时开发随时部署了。那么有什么办法可以实现自动部署呢？
原因就是运行git remote add origin http://45.77.**.**/root/webmaven.git是默认是80端口，由于你修改了80端口，所以就会报错，如果修改为88端口，则应该运行：git remote add origin http://45.77.**.**:88/root/webmaven.git来指明端口。貌似修改了22端口会影响https。
介绍如何在Linux系统使用Docker安装Gitlab、Gitlab-Runner并实现项目的CICD
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
大家好，我是山月，这是我最近新开的专栏：「前端部署系列」。包括 Docker、CICD 等内容，大纲图示如下：
日常开发中，相信大家已经做了很多的自动化运维环境，用的最多的想必就是利用Jenkins实现代码提交到自动化测试再到自动化打包，部署全流水线 Jenkins在devops担任了很重要的角色，但是另一方面相信目前大家的代码版本管理大多都是交给git来管理，在企业私有部署的大背景下，Gitlab由于丰富的插件和细粒度更高的权限控制被大家所采用。 如果只是把Gitlab作为代码版本管理，那就大大浪费他的附加价值，在Gitlab中自带CICD功能，此功能就可完全代替Jenkins，这样一来，我们就不必维护多套系统，简化开发到运维的复杂度 实践 由于gitlab资源消耗严重，本地没有搭建，所以使用gitlab官方
Gitlab实现CICD的方式有很多，比如通过Jenkins，通过Gitlab Runner等，今天主要介绍后者。Gitlab在安装的时候，就默认包含了Gitlab CI的能力，但是该能力只是用于协调作业，并不能真的去执行作业，因此需要搭配Gitlab Runner来作为执行器实现具体的CICD工作。Gitlab Runner可以被安装在任意支持的系统上，比如Linux、Windows、Mac，甚至也可以运行在Docker、Kubernetes集群上。更多关于构建企业自动化运维平台系列的
今天在少珺小伙伴的协助下，使用了 gitlab 的 runner 给全组的项目做自动的构建。为什么需要使用 Gitlab 的 Runner 做自动构建，原因是之前是用的是 Jenkins 而新建一个底层库项目想要接入自动构建等，需要来回在 Gitlab 和 Jenkins 上配置，大概步骤差不多有 20 步，同时还有一堆 Jenkins 的坑。另外服务器是共有的，有其他组的小伙伴安装了诡异的工具让我的打包不断炸掉。于是我就和头像大人商量使用虚拟机环境的方法，我在空闲的服务器上安装了 VirtualBox 虚拟机，然后在虚拟机部署 Runner 接着在项目接入，这样就可以确定打包的环境，同时迁移服务器也比较方便
用过Gitlab的同学基本上都了解过Gitlab持续集成与持续部署，Gitlab CICD是通过自管理的一些Runner按照声明式的的配置清单实现持续集成的自动化任务，利用Github Actions可以自动化管理、构建、部署托管在Github上的代码，当然你可以用它自动化管理和部署你的博客，无需人为干预，也可以利用Actions帮你拉取一些国内拉不到的镜像等，功能有了，至于怎么使用就看个人了，前面我写了几篇关于Gitlab CICD的实践文章以及在Kubernetes上如何使用Gitlab CICD,大家有兴趣的可以前来审校：
大家好，我是「柒八九」。一个「专注于前端开发技术/Rust及AI应用知识分享」的Coder。
@toc 前言 作者主页：https://blog.csdn.net/qq_48450494?type=blog 个人博客：http://ygcloud.work/ Jenkins 是一个持续集成工具
首先需要在linux上安装 gitlab-runner 然后注册一个shell作为执行器的runner 该runner将应用于需要构建的项目
helm3 repo add gitlab https://charts.gitlab.io
目前已经复习了Linux、网络、前后端、docker以及k8s的基础知识，现在就是开始研究持续集成和持续部署也就是CI/CD,目前主流的就是gitlab+自带的cicd流程或者jenkins+docker/k8s作为实现手段，那我们首先安装gitlab，上传代码，然后安装gitlab-runner作为代码的运行环境。将代码部署到k8s集群中，实现快速的代码部署更新迭代，下面就来介绍，可能这篇文章无法全部写完，会持续输出。
* drone-runner启动参数很多，下面解释下： + DRONE_RPC_PROTO： 用于连接 Drone 服务器的协议 + DRONE_RPC_HOST： 提供 Drone 服务器的主机名 + DRONE_RPC_SECRET： 用于向 Drone 服务器进行身份验证的共享密钥 + DRONE_RUNNER_CAPACITY： 限制运行器可以执行的并发管道的数量 + DRONE_RUNNER_NAME： 设置runner的名字
通过gitlab-runner执行绑定的命令：docker exec -it gitlab-runner gitlab-runner register 通过Gitlab创建仓库，并且获取到gitlab信息
每次发布都需要手动“丢包”，不断重复机械化的工作，可想而知效率会有多慢，而且更难保证每次每个步骤都不会疏忽，可能忘记做单元测试就进行了代码提交，造成程序出错等
打开/etc/gitlab/gitlab.rb配置文件，查看一个和备份相关的配置项：
在之前编写过CI与Gitlab的整合应用，下来主要详细的介绍使用Gitlab工具的CI的可持续应用。搭建好Gitlab的环境好后，我们需要在Linux的环境安装Gitlab的插件gitlab-ci，安装命令为：
GitLab：是一个基于Git实现的在线代码仓库托管软件，你可以用gitlab自己搭建一个类似于Github一样的系统，一般用于在企业、学校等内部网络搭建git私服。
GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的Web服务。
安装系统：linux Docker版本：Docker version 19.03.5, build 633a0ea
服务架构的轻量化一直都是很多架构师的追随目标，慢慢的演变成现在的微服务的使用，轻量简洁的服务架构不仅仅减少技术人员的维护压力，还大大的降低了技术人员的学习成本。
客户端新增hots记录192.168.10.10 gitlab.local.com
使用GitLab自带的流水线，必须要定义流水线的内容，而定义内容的文件默认叫做.gitlab-ci.yml，使用yml的语法进行编写。 目前任务关键词有28个，全局的关键词有10个，两者重叠的有很多。今天我给大家先讲解一下常用的关键词，掌握了这些关键词的用法，你可以编写逻辑严谨，易于扩展的流水线。
本文是学习B站毛剑老师的《API 工程化分享》的学习笔记，分享了 gRPC 中的 Proto 管理方式，Proto 分仓源码方式，Proto 独立同步方式，Proto git submodules 方式，Proto 项目布局，Proto Errors，服务端和客户端的 Proto Errors，Proto 文档等等
修改Runner的 /etc/gitlab-runner/config.toml文件，在其中的 [runner.docker]下增加：
持续集成（Continuous integration）：持续集成指的是，频繁地（一天多次）将代码集成到主干。
源码地址：https://github.com/limingios/docker-cloud-flask-demo
Jenkins是一个广泛用于持续构建的可视化web工具，可用于自动化与构建、测试、交付或部署软件相关的各种任务。 可以通过安装包、tomcat、java、docker方式进行安装使用
[TOC] 0x00 前言简述 CI/CD介绍 Q：我们常说的CI/CD是什么? CI 为 Continuous Integration 的缩写持续集成，可以理解为代码变动提交后，自动执行代码编译、代
本文将展示整个持续集成过程的搭建，这对于devops运维工程师来说是很轻松的事情，这里更想给新手开发人员，特别是前端开发人员对于CICD的基础参考，整个过程实践包含以下三点：
GitLab 是一个用于仓库管理系统的开源项目，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。
领取专属 10元无门槛券
手把手带您无忧上云
