什么是 CI/CD 经验

目前尚不清楚雇主在需要 CI/CD 经验时的意思。典型的开发人员应该能够使用 git 或 mercurial，仅此而已。直接集成和部署由系统管理员或经验丰富的团队开发人员配置的服务器脚本完成。

了解如何配置以及可以配置哪些内容只需几天时间。你可以自己写这样的东西，依靠所谓的版本控制钩子，但现在通常他们使用带有 GUI 的构建服务器。

当谈到CI / CD容器时，他们很可能是指 Docker。一个非常方便的解决方案，大大简化了隐藏在CD中字母D后面的东西，即部署。

例子。为确保新代码不会破坏任何内容，在构建项目并运行单元测试之后，您可以部署集成测试循环。为此，您需要使用数据库映像和新程序集运行多个 Docker 容器。在测试电路上，您可以运行脚本来检查系统是否作为一个程序集工作 - 从伸出的 API 到位于内部的数据库。

我再次重申，这背后没有真正的魔法，一切都在几天内掌握。

我想提请注意的是协作开发的文化。学习 git 命令并不是很困难，尽管它们有点令人困惑。养成对团队合作有用的习惯要困难得多。

• 短枝。没有经验的开发人员经常会在他们的分支机构中呆上几天。在此期间，代码设法跑得远远的。即使他们接受了变化，大型合并的可能性也会增加。这里的规则是：分解任务，以便在几个小时内完成每个任务。最好不要将未完成的任务留到明天。

• Microfixations，即微提交。每个提交应该包含几个文件，并且应该用一句话描述其目的。这对于方便的代码审查是必要的。在工作时，您经常会发现一些文件包含问题的解决方案，而其中一些文件包含重构。git 允许您首先将一些更改的文件添加到第一个提交，然后将其他文件添加到第二个。

• 夹具名称。进行 git 提交时，请务必使用有意义的文本填写注释。许多人没有，而且徒劳无功。不利于代码审查。

这些规则需要很长时间才能掌握，而且通常伴随着一些令人不快的事情：合并失败、代码审查困难、团队斗争。但是，当这一切都过去后，工作变得更容易和更快。

CI代表持续集成，简单来说，就是将源代码的更改频繁发送到服务器并自动组装和测试的一种开发方式。CD（持续部署），这个是类似的，但是除了组装之外，代码会自动部署到最终使用（例如，为Web应用程序布局在Web服务器上，或者为桌面应用程序打包到目标OS安装包中） . 如果使用Docker，CI 容器显然只是在其中发生这些操作的 Docker 容器。CI 的理论大部分在这里描述：什么是持续集成？

CI 的一个实际示例是使用 GitHub Actions 自动构建 .NET Core 应用程序。

让我们创建一个 GitHub 存储库并使用 C# .NET Core 测试项目填充它

让我们转到 GitHub 操作选项卡

对于使用 C# 代码的项目，系统会自动建议创建一个 .NET Core 工作流。单击“设置此工作流程”按钮。系统会提示您创建模板 dotnetcore.yml 配置文件：

name: .NET Core

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 2.2.108
    - name: Build with dotnet
      run: dotnet build --configuration Release

在这里，我们看到两个标准步骤：安装所需版本的 .NET Core SDK 并使用 dotnet build 命令运行构建。让我们添加两个步骤：归档构建结果并运行生成的应用程序：

name: .NET Core

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
    - name: Setup .NET Core
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: 2.2.108
    - name: Build with dotnet
      run: dotnet build CoreTest.sln --configuration Release
    - name: Archive build results
      uses: actions/upload-artifact@v1
      with:
          name: Output
          path: NetCoreTest/bin/Release/
    - name: Run
      run: |        
        dotnet NetCoreTest/bin/Release/netcoreapp2.1/NetCoreTest.dll

让我们修复结果。现在，将每个更改推送到存储库后，我们可以自动查看构建结果：

这些结果显示为对 Pull 请求的检查（在 Checks 选项卡上） - 您可以强制检查，然后如果构建失败，则无法合并更改。最大的优势是我们始终可以确保应用程序在 Linux 上有效，即使没有使用此操作系统的本地计算机。在这种情况下，在底层，不是 Docker，而是 Azure 虚拟机，所以没有 CI 容器（有一个虚拟 CI 环境）。

配置了 CI 的示例存储库：https ://github.com/MSDN-WhiteKnight/CoreTest