GitLabCI/CD是GitLab内置的一个工具，通过持续的方法进行软件开发：：ContinuousDeliveryContinuousDeployment(CD):ContinuousDeployment持续集成工作通过将小块代码推送到Git存储库中托管的应用程序代码库，每次推送时，都会运行一系列脚本来构建、测试和验证代码更改，然后再将它们合并到主分支中。持续交付和部署相当于CI，将应用程序部署到生产环境，每次推送到存储库的默认分支。这些方法可以在开发周期的早期发现缺陷和错误，确保部署到生产环境的所有代码都符合为应用程序建立的代码标准。GitLabCI/CD由位于存储库根目录中的名为.gitlab-ci.yml的文件配置。文件中指定的脚本由GitLabRunner执行。GitLabCI/CD引入了一种基于自动执行脚本的持续软件开发方法，以最大限度地减少在开发应用程序时引入错误的机会。他们从开发新代码到部署它，几乎没有人为干预。它涉及在小迭代中不断构建、测试和部署代码更改，减少基于已经存在错误或失败的先前版本开发新代码的机会。持续集成假定一个应用程序，其代码存储在GitLab的Git存储库中。开发人员每天多次推送代码更改。对于每次推送到存储库，您可以创建一组脚本来自动构建和测试您的应用程序，从而减少将错误引入应用程序的机会。这种做法称为持续集成，它会自动持续地构建和测试您提交给应用程序（甚至是开发分支）的每个更改，确保您引入的更改通过您为应用程序、指南和代码建立的所有测试合规标准。ContinuousDelivery（持续交付），持续交付是持续集成之外的进一步操作。不仅是通过将每个代码更改推送到代码库来构建和测试应用程序，而且，尽管部署是手动触发的，但作为附加步骤，它也可以持续部署。这种方法可确保自动检查代码，但需要从策略中手动触发人工干预以确认更改。ContinuousDeployment（持续部署），类似于持续交付，不同的是它不是手动部署，而是可以设置为自动部署。完全无需人工??干预即可部署您的应用程序。GitLabCI/CD的工作原理为了使用GitLabCI/CD，您需要一个托管在GitLab上的应用程序代码存储库，其中包含在根目录中的.gitlab-ci.yml文件中指定的构建、测试和部署脚本。在此文件中，您可以定义要运行的脚本、定义要包含的依赖项、选择要顺序运行的命令和并行运行的命令、定义应用程序的部署位置，以及指定是自动运行脚本还是手动触发脚本。为了可视化该过程，假设添加到配置文件的所有脚本都是在计算机终端上运行的相同命令。将.gitlab-ci.yml添加到存储库后，GitLab将检测到此文件并使用名为GitLabRunner的工具运行脚本。该工具像终端一样运行。这些脚本被分组为作业，它们一起形成一个管道。一个最简单的.gitlab-ci.yml文件可能如下所示：before_script:-apt-getinstallruby??gemsruby??-dev-yrun-test:script:-ruby??--version6before_script属性将为您的应用程序安装依赖项，一个名为run-test的作业将打印当前系统的Ruby版本。它们一起形成了一个流水线，每次推送到存储库的任何分支时都会触发该流水线。GitLabCI/CD不仅可以执行您设置的作业，还可以显示执行过程中发生的情况，就像您在终端中看到的那样：为您的应用程序创建策略，GitLab将根据您的定义运行Pipeline。GitLab还会显示管道的状态：最后，如果出现任何问题，可以轻松回滚所有更改：基本CI/CD工作流程CI/CD管道将被触发。GitLabCI/CD通过以下方式做到这一点：运行自动化脚本（串行或并行）代码审查并获得批准构建和测试您在本地计算机上看到的应用程序使用ReviewApps代码审查和批准预览每个合并请求的更改合并功能分支到默认分支，并自动将此更改部署到生产环境。如果出现问题，您可以通过GitLabUI轻松回滚。所有步骤都可视化。深入了解基本CI/CD工作流程如果我们深入了解基本工作流程，我们可以看到GitLab在DevOps生命周期的每个阶段可用的功能，如下图所示：验证：自动构建和测试您的应用程序使用GitLab代码质量分析您的源代码质量通过浏览器性能测试确定代码更改对性能的影响使用ReviewApps执行一系列测试，例如容器扫描、依赖扫描、JUnit测试部署更改以在每个分支更改包上预览应用程序：使用ContainerRegistry存储Docker镜像使用NPMRegistryStore存储Maven工件使用ConanRepositoryStoreConanpackages使用ConanRepositoryRelease：持续部署，自动部署您的应用程序将应用程序部署到生产环境持续交付，手动单击以将您的应用程序部署到生产环境静态部署具有GitLabPages的网站仅将功能部署到一个Pod，并让一定比例的用户群通过CanaryDeployments（PS：灰色发布）访问临时部署的功能在功能标志之后部署功能使用GitLabReleases将发布说明添加到任何Git标签使用Deploy用于查看运行在Kubernetes上的每个CI环境的当前运行状况和状态的面板使用AutoDeploy部署应用程序部署到Kubernetes集群中的生产环境使用GitLabCI/CD，您还可以：使用GitLabCI/CD轻松设置应用程序的整个生命周期AutoDevOps将您的应用程序部署到不同的环境安装您自己的GitLabRunnerSchedule管道使用安全测试报告）检查应用程序漏洞GitLabCI/CD快速入门.gitlab-ci.yml文件告诉GitLabRunner要做什么。一个简单的流水线通常包括构建、测试、部署三个阶段，流水线在CI/CD>流水线页面。创建一个.gitlab-ci.yml文件，通过配置.gitlab-ci.yml文件来告诉CI如何处理你的项目。它位于存储库的根目录。一旦存储库收到任何推送，GitLab将查找.gitlab-ci.yml文件并根据文件的内容在Runner上启动作业。下面是一个Ruby项目配置的例子：image:"ruby:2.5"before_script:-apt-getupdate-qq&&apt-getinstall-y-qqsqlite3libsqlite3-devnodejs-ruby??-v-whichruby-gemlerinstall-bundle-no-document-bundleinstall--jobs$(nproc)"${FLAGS[@]}"rspec:script:-bundleexecrspecrubocop:script:-bundleexecrubocop在上面的例子中，定义了两个作业，分别是rspec和rubocop。在每个作业开始执行之前，必须先执行before_script下的命令。将.gitlab-ci.yml推送到GitLabgitadd.gitlab-ci.ymlgitcommit-m"Add.gitlab-ci.yml"gitpushoriginmaster在GitLab中配置一个Runner，Runner运行你在.gitlab-ci中定义的。yml中的作业。Runner可以是虚拟机、物理机、Docker容器或容器集群。GitLab和Runner通过API进行通信，所以只需要Runner所在的机器有网络，并且可以访问GitLab服务器即可。您可以转到设置?CI/CD以查看是否已经有与您的项目关联的Runner。设置Runner简单明了。查看流水线和作业的状态成功配置Runner后，您应该能够看到最近提交的状态。要查看所有作业，您可以转到Pipelines?Jobs页面。通过单击作业的状态，您可以看到作业运行的日志。回顾一下：首先，定义.gitlab-ci.yml文件。在此文件中，定义了要执行的作业和命令。然后，将文件推送到远程仓库。最后，Runner被配置为运行作业。AutoDevOpsAutoDevOps提供预定义的CI/CD配置，允许您自动检测、构建、测试、部署和监控应用程序。借助CI/CD最佳实践和工具，AutoDevOps旨在简化成熟和现代软件开发生命周期的设置和执行。借助AutoDevOps，软件开发流程的设置变得更加容易，因为每个项目都可以通过最少的配置完成从验证到监控的完整工作流程。只需推送您的代码，GitLab就会处理其他一切。这使得启动新项目变得更加容易，并使整个公司的应用程序设置方式保持一致。以下示例展示了如何使用AutoDevOps将托管在GitLab.com上的项目部署到GoogleKubernetesEngine。该示例将使用GitLab的原生Kubernetes集成，因此无需单独手动创建Kubernetes集群。此示例将创建和部署从GitLab模板创建的应用程序。从GitLab模板创建项目在创建Kubernetes集群并将其连接到GitLab项目之前，您需要一个GoogleCloudPlatform帐户。让我们使用GitLab的项目模板创建一个新项目。为项目命名并确保它是公开的。通过单击“添加Kubernetes集群”按钮或“操作”>“Kubernetes”从GitLab模板创建Kubernetes集群。安装Helm、Ingress和Prometheus。启用AutoDevOps（可选）默认情况下启用AutoDevOps。导航到设置>CI/CD>AutoDevOps。选中默认为自动DevOps管道。最后选择部署策略。完成上述所有操作后，将自动创建一个新的Pipeline。要查看管道，请转到CI/CD>管道。部署应用程序现在，您应该看到管道正在运行，但它到底在运行什么？流水线分为4个阶段。我们可以看到每个阶段运行了多少个作业，如下图：Build->Test->Deployment->PerformanceTest现在应用已经部署成功，我们通过浏览器查看一下。首先，导航到Operations>Environments。在环境中，您可以查看已部署应用程序的详细信息。在最右边有三个按钮，让我们依次浏览它们：第一个图标将打开在生产中部署的应用程序的URL。这是一个非常简单的页面，但重要的是它有效！第二个旁边是一个带有小图像的图标，Prometheus将在其中收集有关Kubernetes集群的数据以及应用程序如何影响它（在内存/CPU使用率、延迟等方面）。第三个图标是Web终端，它将在运行应用程序的容器内打开一个终端会话。示例使用GitLabCI/CD部署SpringBoot应用程序。示例.gitlab-ci。隔离：java：8个阶段：-构建-部署前_script：-chmod+xmvnwbuildbuild：stage：构建脚本：./mvnwpackagetrakefacts：paths：partion/target/target/demo-demo-0.0.0.0.1-snapshot。jar生产：阶段：部署脚本：-curl--location“https://cli.run.pivotal.io/stable?release=linux64-binary&source=github”|tarzx-./cf登录-u$CF_USERNAME-p$CF_PASSWORD-aapi.run.pivotal.io-./cf仅推送：-master
