Docker和Spring Boot是非常流行的组合，我们将利用GitLab CI的优势，并在应用程序服务器上自动构建，推送和运行Docker镜像。
在我们完成项目开发后，提交到git，当监听提交后，自动进行编译，并进行项目的部署，是不是一想就很爽，所以下面引入我们的主角 —— gitlab-CI，中文文档 。
CI/CD 是持续集成(Continuous Integration)和持续部署(Continuous Delivery/Deployment)的缩写。
目的是通过一个示例应用程序对GitLab CI/CD进行友好的了解，该应用程序有助于入门，而无需阅读所有GitLab文档。
容器化正迅速成为在云环境中打包和部署应用程序的最常用方法。它提供的标准化，以及其资源效率和灵活性，使其成为现代DevOps思维模式的重要推动者。当您的应用程序和微服务完全集装箱化时，许多有趣的云本机部署，编排和监控策略都成为可能。
首先是测试用例，最初我们设计在了 git hooks 里边，在执行 git commit 之前会进行检查，在本地运行测试用例。 这会带来一个时间上的问题，如果是日常开发，这么操作还是没什么问题的，但如果是线上 bug 修复，执行测试用例的时间依据项目大小可能会持续几分钟。 而为了修复 bug，可能会采用 commit 的时候添加 -n 选项来跳过 hooks ，在修复 bug 时这么做无可厚非，但是即使大家在日常开发中都采用commit -n 的方式来跳过繁琐的测试过程，这个也是没有办法管控的，毕竟是在本地做的这个校验，是否遵循这个规则，全靠大家自觉。
来源 | https://juejin.im/post/5cef97e0e51d45776031af91
大家好，我是山月，这是我最近新开的专栏：「前端部署系列」。包括 Docker、CICD 等内容，大纲图示如下：
GitLab当前不支持在构建环境（运行GitLab Runner的环境）中管理SSH密钥的内置支持。
作为一个个人开发者，在业余时间也会想着开发一些个人的好玩的项目，去开发一些效率工具，开发一些自己喜欢的程序，在这个前提下，很多人购买了自己的服务器，作为一个前端开发，在最开始的时候对服务器相对会比较陌生，如果接触不多，在部署自己的项目过程中也会有许许多多的不便，我们也可以为自己搭建一套自动化部署，能够让我们在开发个人项目的时候享受同样的便捷。
发现文件和文件夹的颜色都是红色 ,当出现这种情况的时候, 说明这些文件还没有添加到git仓库当中
1）在上图红圈2部分设置需要跟踪变化的分支，根据上面的选项配置，可以是允许全部分支的变化触发构建，也可以设置只是具体的某些分支触发，这里示例是允许master分支上的变化触发构建。
本篇是系列中的第五篇内容，我们继续聊聊如何把一个简化过的私有云环境部署在笔记本里，以满足低成本、低功耗、低延时的实验环境。如果你有闲置的轻量云服务器，也可以动手试试。
两年前在开始一个新的商业项目时我花了两个星期时间在项目开发流程中应用上了持续集成，随后一年又随着项目的发展和商用化做了很多改进。所以掌握了GitLab 持续集成这套方案在商业软件中完整的落地实践经验。文章最早发布在其他平台，当时引起了不少关注，内容虽然是对一个PHP项目持续集成的设置，但是整个持续集成是完全容器化的，这套解决方案可以很方便的应用于任何编程语言的项目。希望文章能对你有所帮助和启发。
许多CI / CD系统工具为开发团队和DevOps团队提供了源代码控制，构建工件和部署功能等功能。GitLab就是其中之一，但是该产品为CI / CD管道带来了某些优势，从易于安装到高级自动化。基于Web的工具鼓励团队内适当的代码实践，并安全地部署到生产中。
本教程将讲解如何依托腾讯云主机(CVM)，以Docker方式搭建Gitlab服务。具体将包括：Docker安装，Gitlab安装与配置，Gitlab的开发流程示例，以及基于Gitlab的持续集成(CI/CD)的介绍。
最近看了@Tualatrix Chou所写的使用 jsDelivr 来优化网站访问速度,深受启发又加之自己采用Hexo博客框架搭建了一个静态化的博客,同时采用github Page 进行托管，虽然加上Cloudflare的CDN来加速，但是实际上某些情况下还没有直接访问的速度快，当然加了总比没加好;
为什么要考虑自己搭建和部署代码托管平台呢？一方面，自托管的代码托管平台可以给团队提供更高的灵活性和定制化能力。你可以根据团队的需求和安全要求进行自定义配置，而不受公共托管平台的限制。另一方面，自己搭建代码托管平台还可以加强数据的安全性和隐私保护。你完全掌握数据的存储和访问权限，减少了数据泄露和安全漏洞的风险。
在过去几年的DevOps的浪潮中，自动化、持续集成这两个概念早已深入人心(互联网技术人)。比尔盖茨先生曾经都说过：“任何技术在一个业务中使用的第一条规则就是，将自动化应用到一个高效的操作上将会放大高效。第二条就是自动化应用到一个低效操作上，则放大了低效率。”
网上有很多安装gitlab的方法，这里推荐使用docker安装，真的超级超级方便。 这里有一篇文章 docker安装配置gitlab详细过程 https://www.cnblogs.com/zuxing/articles/9329152.html 这里就不细说了。毕竟重点不是说怎么安装gitlab哈哈哈。
如果你用Gitlab作为Git仓库的话，使用它的CI/CD功能来实现自动化部署确实很不错！安装一个轻量级gitlab-runner，编写简单的.gitlab-ci.yml脚本文件即可实现。其实我们之前以及介绍过很多种自动化部署方案，比如Jenkins、Gogs+Drone、Gitlab CI/CD，我们可以发现一个共同点，这些方案都离不开Linux命令。所以说要想玩转自动化部署，还是得先玩转Linux命令！
做为一个略微看过nodejs语法，但又不懂nodejs的攻城狮，搭建hexo环境很是麻烦，要考虑到翻墙、版本兼容等问题。于是乎，博主每换一个电脑，为了能继续发博客，都需要在新电脑上花一天时间重新搞一下 hexo 环境，楼主感觉还是有简洁的方案来实现我一提交代码就可以自动发布博客，不需要再手动操作一波，这样岂不美哉。so，也就有了今天的经历，代码可以持续集成，博客也可以。楼主的解决方案是使用gitlab与gitlab-runner实现博客部署的持续集成，效果真的不要太好。
一.在window中安装Git 版本要求：Git-2.22.0-64-bit.exe或以上版本， 安装路径：请不要安装在C盘(win10会有权限问题)，建议选择“D:\tools\Git”
DevOps 正在改变全球软件开发的状态，DevOps 正以某种形式有效地提高提高全球软件公司的上市速度、可销售性、创新和产品质量。
Argo CD不直接使用任何数据库（Redis被用作缓存），所以它看起来没有任何状态。之前，我们看到了如何实现高可用性的安装，主要是通过增加每个部署的副本数量来完成的。但是，我们也有应用程序定义（如Git源集群和目标集群），以及关于如何访问Kubernetes集群或如何连接到私有Git回购或私有帮助集群的详细信息。这些东西构成了Argo CD的状态，它们保存在Kubernetes资源中——要么是本地资源，比如连接细节的秘密，要么是应用程序和应用程序约束的自定义资源。 灾难可能会由于人工干预而发生，例如Kubernetes集群或Argo CD名称空间正在被删除，或者可能是一些云提供商出现的问题。我们也可能有要将Argo CD安装从一个集群移动到另一个集群的场景。例如，也许当前的集群是用我们不想再支持的技术创建的，比如kubeadm（https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/），现在我们想转移到云提供商管理的技术。 你可能会出现在脑海中：“但我认为这是GitOps，所以一切都保存在Git回购中，这意味着它很容易重新创建？”首先，并不是所有的东西都被保存到Git回购中。例如，当在Argo CD中注册一个新集群时，我们必须运行一个命令，使这些详细信息不在Git中（出于安全原因，这是可以的）。其次，重新创建GitOps回购中的一切可能需要很多时间——可能有数千个应用程序、数百个集群和成千上万的Git回购。更好的选择可能是从备份中恢复到以前的所有资源，而不是从头开始重新创建所有的资源；这样做要快得多。
CI/CD 是 Continuous Intergration/Continuous Deploy 的简称，翻译过来就是持续集成/持续部署。CD 也会被解释为持续交付（Continuous Delivery），但是对于软件工程师而言，最直接接触的应该是持续部署。
CI/CD：持续集成/持续交付 程序语言： 解释执行：shell / python / php 编译执行：c / c++ / go / java # vim hello.c #include <stdio.h> int main(void){ printf("Hello World!\n"); return 0; } # gcc -o hello hello.c # ./hello graph LR dev(程序员)--推送-->git(git server) ci(jenkins)--
[TOC] 0x00 前言简述 Q：我们常说的CI/CD是什么？ CI 为 Continuous Integration 的缩写持续集成，可以理解为代码变动提交后，自动执行代码编译、代码打包、代码测试
之前项目中虽然使用过 Jenkins，但是都只是使用，没有自己搭建过，完整部署一个项目。既然工作中没有独立部署过，那么就只能自己动手实操一番，技多不压身嘛。
一、GitLab简介 GitHub是2008年由Ruby on Rails编写而成，与业界闻名的Github类似;但要将代码上传到GitHub上面，而且将项目设为私有还要收费。GitLab 是一个用于
在上一篇文章中，我们介绍了如何使用Docker搭建自己的GitLab代码托管平台。
因此，在本文中，我们就从「[版本控制简史」出发，揭开「基于 Git 的版本控制工作流」的神秘面纱。
博主说：本文借鉴了很多「 DRPrincess」博主的文章内容，在此对其表示感谢。
DevOps 是 Development（开发）和 Operations（运维）的组合，是 ⼀种⽅法论，是⼀组过程、⽅法与系统的统称，⽤于促进应⽤开发、应2 ⽤运维和质量保障（QA）部⻔之间的沟通、协作与整合，以期打破传 统开发和运营之间的壁垒和鸿沟 CI/CD 的主要概念是持续集成、持续交付和持续部署。 CI/CD 是解决集成新代码可能给开发和运营团队带来的问题（⼜名“集 成地狱”）的解决⽅案。
在这篇文章中，将介绍在GitLab上使用GitLab CI轻松实现单元测试自动化的方法。
https://github.com/zq2599/blog_demos 内容：所有原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等；
1.1 前言 Jenkins是一个用Java编写的开源的持续集成工具。在与Oracle发生争执后，项目从Hudson项目独立。 Jenkins提供了软件开发的持续集成服务。它运行在Servlet容器中
理解了上面的基本概念之后，有没有觉得少了些什么东西 —— 由谁来执行这些构建任务呢？ 答案就是 GitLab Runner 了！
持续集成 (Continuous integration)是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
越来越多的工程团队正在采用敏捷开发，推动更短，更快的发布周期。代码库增长和创建新生产构建的频率导致持续集成和持续部署/交付工具的兴起。
GitLab CI/CD 是一个内置在 GitLab 中的工具，用于通过持续方法进行软件开发：
在本文中，我将介绍如何基于 GitLab 和 GitLab Runner 进行 CI/CD 部署。GitLab 是一个强大的 Git 仓库管理系统，提供了完整的 CI/CD 管理功能。GitLab Runner 是一个用于运行 CI/CD 作业的轻量级容器化工具。我们将使用 Docker 容器来运行 GitLab 和 GitLab Runner。
https://buoyant.io/2020/09/16/linkerds-ci-kubernetes-in-docker-github-actions/
什么是 Gitlab 一个开源分布式版本控制系统 开发语言：Ruby 功能：管理项目源代码、版本控制、代码复用与查找、权限管控 Git 家族成员 Git：是一种版本控制系统，是一个命令，是一种工具 Gitlib：是用于实现 Git 功能的开发库 Github：是一个基于 Git 实现的在线代码托管仓库，包含一个网站界面，向互联网开放 GitLab：是一个基于 Git 实现的在线代码仓库托管软件，你可以用 Github 自己搭建一个类似于 Github 一样的系统，一般用于在企业、学校等内部网络搭建 git
来源丨 www.cnblogs.com/cjsblog/p/12256843.html
GitLab有CI和CD功能模块，但我对Jenkins更熟悉些，所以先使用Jenkins将自动发布搭建起来，后面再继续研究GitLab的CI和CD功能。
持续集成（Continuous integration，简称CI）指的是，频繁地（一天多次）将代码集成到主干。
在《体验SpringBoot(2.3)应用制作Docker镜像(官方方案)》一文中，咱们掌握了SpringBoot官方推荐的镜像构建方案，接下来要体验的是GitLab的CI能力，它负责把代码变成私有仓库中的镜像，咱们可以专心编码了；
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
