软件开发的连续方法基于自动执行脚本，以最大程度地减少在开发应用程序时引入错误的机会。从开发新代码到部署新代码，他们几乎不需要人工干预，甚至根本不需要干预。
它涉及到在每次小的迭代中就不断地构建，测试和部署代码更改，从而减少了基于错误或失败的先前版本开发新代码的机会。
此方法有三种主要方法，每种方法都将根据最适合您的策略的方式进行应用。
持续集成
考虑一个应用程序，其代码存储在GitLab的Git存储库中。开发人员每天要多次推送代码更改。对于每次向存储库的推送，您都可以创建一组脚本来自动构建和测试您的应用程序，从而减少了向应用程序引入错误的机会。
这种做法被称为持续集成[1]；对于提交给应用程序（甚至是开发分支）的每个更改，它都会自动连续地构建和测试，以确保所引入的更改通过您为应用程序建立的所有测试，准则和代码合规性标准。
持续交付
持续交付[2]是超越持续集成的一步。您的应用程序不仅会在推送到代码库的每次代码更改时都进行构建和测试，而且作为附加步骤，尽管部署是手动触发的，但它仍会持续部署。
此方法可确保自动检查代码，但需要人工干预才能从策略上手动触发更改的部署。
持续部署
与持续交付类似，持续部署[3]也是超越持续集成的又一步。区别在于，您无需将其手动部署，而是将其设置为自动部署。部署您的应用程序完全不需要人工干预。
GitLab CI / CD如何工作
要使用GitLab CI / CD，您需要做的是托管在Git存储库中的应用程序代码库，并.gitlab-ci.yml[4]在存储库根路径中名为的文件中指定构建，测试和部署脚本。
在此文件中，您可以定义要运行的脚本，定义包含和缓存依赖项，选择要按顺序运行的命令和要并行运行的命令，定义要在哪里部署应用程序，以及指定是否将要自动运行脚本或手动触发任何脚本。熟悉GitLab CI / CD后，您可以在配置文件中添加更多高级步骤。
要将脚本添加到该文件，您需要按照适合您的应用程序并符合您要执行的测试的顺序来组织它们。为了可视化该过程，假设添加到配置文件中的所有脚本与在计算机的终端上运行的命令相同。
将.gitlab-ci.yml配置文件添加到存储库后，GitLab将检测到它并使用名为?GitLab Runner的工具运行脚本，该工具的工作原理与终端类似。
这些脚本被分组为作业，它们共同组成了一个管道。.gitlab-ci.yml文件的简约示例可以包含：
before_script:
- apt-get install rubygems ruby-dev -y
run-test:
script:
- ruby --version
该before_script属性将在运行任何内容之前为您的应用程序安装依赖项，并且名为 的作业run-test将打印当前系统的Ruby版本。它们都组成了在每次推送到存储库的任何分支时触发的管道。
GitLab CI / CD不仅执行您已设置的作业，而且还向您显示执行期间发生的情况，就像您在终端中看到的那样：
工作运行
您为您的应用程序创建策略，GitLab根据您定义的内容为您运行管道。您的管道状态也会由GitLab显示：
管道状态
最后，如果出现任何问题，您可以轻松 回滚[5]所有更改：
回滚按钮
基本的CI / CD工作流程
考虑以下示例，以了解GitLab CI / CD如何适合通用开发工作流程。
假设您已在一个问题中讨论了代码实现，并在本地进行了建议的更改。将提交推送到GitLab中的远程存储库中的功能分支后，将触发为项目设置的CI / CD管道。这样，GitLab CI / CD：
- 将自动化脚本（顺序或并行）运行到：
- 构建并测试您的应用。
对实施感到满意后：
- 让您的代码得到审查和批准。
- 将功能分支合并到默认分支。
- GitLab CI / CD将您的更改自动部署到生产环境。
- 最后，如果出现问题，您和您的团队可以轻松地将其回滚。
如上图所示，当创建一个分支之后，你可以根据自己的需要在.gitlab-ci.yml文件中设定各种需要的构建和测试的场景，一旦你将本地的代码推送到代码仓库，Gitlab上相关的gtilab-runner就会按照预先设定的场景.gitlab-ci.yml执行你的构建和单元测试，直到所有的任务都通过之后，就会自动或者通过手动触发部署你的服务到对应的服务器上，在服务部署完成后，测试没有问题了，此时就可以发起一个新的merge请求，将这个构建、部署、测试没有问题的功能分支合并到主分支上，然后继续服务的持续交付环节。
深入了解CI / CD基本工作流程
如果我们深入研究基本工作流程，则可以在DevOps生命周期的每个阶段看到GitLab中可用的功能，如下图所示。
Deeper look into the basic CI/CD workflow
在基本上熟悉Gitlab持续集成、持续部署、持续交付之后，我们可以对每个环节进行更加深入的研究,我们可以在
- verify环节
- 通过持续集成自动构建和测试您的应用程序
- 使用GitLab代码质量[6]分析您的源代码质量。
- Package
- 使用Container Registry[7]存储Docker映像。
- release发布
- 持续部署，自动将您的应用程序部署到生产环境。
- 持续交付，手动触发部署应用程序到生产环境
- 使用Gitlab Pages[8]部署静态页面
- 使用GitLab Releases[9]向任何Git标签添加发行说明。
- 使用Auto Deploy[10]将应用程序部署到Kubernetes集群中的生产环境。
使用GitLab CI / CD，您还可以：
- 通过?Auto DevOps轻松设置应用程序的整个生命周期。
- 将您的应用程序部署到不同的?环境。
- 安装您自己的?GitLab Runner。
- ?计划管道(schedule pipeline)。
这是Gitlab 持续集成的简单介绍，下一步我将通过专辑的方式一点一点的介绍Gitlab中持续集成和部署是怎么使用的。
最后我们进行一个小小的投票，调查一下你最喜欢的CICD工具:
参考资料
[1]
持续集成: https://en.wikipedia.org/wiki/Continuous_integration
[2]
持续交付: https://continuousdelivery.com/
[3]
持续部署: https://www.airpair.com/continuous-deployment/posts/continuous-deployment-for-practical-people
[4]
.gitlab-ci.yml格式参考: https://docs.gitlab.com/ee/ci/yaml/README.html
[5]
回滚: https://docs.gitlab.com/ee/ci/environments/index.html#retrying-and-rolling-back
[6]
code quality: https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html
[7]
container registry: https://docs.gitlab.com/ee/user/packages/container_registry/index.html
[8]
Gitlab Pages: https://docs.gitlab.com/ee/user/project/pages/index.html
[9]
GitLab Releases: https://docs.gitlab.com/ee/user/project/releases/index.html
[10]
Auto Deploy: https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-deploy
