# CI/CD

前言
什么是CI?
- CI有什么特点？
什么是CD？
- CD有什么特点？
自动化部署工具
GitHub Actions介绍
GitHub Actions 配置步骤
如何配置yml文件？
业内常用的workflow
总结
参考文章

# 前言

在开发过程中，如果项目采用的是CI/CD模式，那么需要开发者频繁的提交代码，合并到主干分支上。并将项目打包部署到服务器上，交付给质量团队或者用户。在通过评审之后，他们将部署到生产环境。但由于编码、构建、集成、测试、交付、部署这些机械性的操作，需要团队持续不断地重复去实行，需要人力及时间成本，因此 自动化部署工具 便问世了。

# 什么是CI?

Continuous Integration(CI)----持续集成，是一个开发行为，它要求开发者每天多次将代码集成到一个共享的仓库，每次提交都会被自动构建所检查，团队可因此提前检测出问题。

# CI有什么特点？

快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易；
防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

# 什么是CD？

Continuous deployment (CD)----持续部署。通过自动化部署的手段将软件功能频繁的进行交付。
Continuous Delivery(CD)----持续交付。指频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

# CD有什么特点？

代码通过评审以后，自动部署到生产环境。
代码在任何时刻都是可部署的，可以进入生产阶段。

# 自动化部署工具

自动化部署工具简单来说，就是将繁杂的步骤写在一个文件中，只要配置好指定分支、代码环境、目标地址等信息，再配置好哪些操作会触发自动部署即可。

TIP

读者可以按照个人喜好选择部署工具。 21种常用自动化部署工具介绍 (opens new window)。

# GitHub Actions介绍

上述说明，持续集成由很多操作组成，比如拉取最新代码、运行测试、登录服务器、部署服务器等，GitHub 把这些操作统一称为 Actions ，并推出持续集成工具 ---- GitHub Actions。

# GitHub Actions 配置步骤

# 一、获取token

进入GitHub
->Settings
->Developer Settings
->Personal access tokens
申请token名字建议写成 ACCESS_TOKEN
勾选workflow,勾选repo下的所有项，以及user下的所有项，生成一个token,复制token值。

WARNING

注意：token在生成之后的那个页面可以看到。如果重新进入，或以后进入，则无法查看，只能通过再生成。

# 二、为指定仓库授权

将上一步生成的ACCESS_TOKEN,设置在指定仓库的Secrets里，便能在脚本文件中使用。目的是为了拥有访问权限。

登录GitHub
点击进入需要自动部署的仓库
在setting中找到Secrets
点击Secrets子菜单下的Actions
在页面右侧点击New repository secret
note名也设置为ACCESS_TOKEN，将Personal access tokens的ACCESS_TOKEN生成值放入。

# 三、项目根目录创建Yml文件

TIP

Yml是什么？我们集成 Github Action 的做法，就是在我们仓库的根目录下，创建一个 .github 文件夹，里面放一个 *.yml 文件——这个 Yml 文件就是我们配置 Github Action 所用的文件。它是一个非常容易地脚本语言，如果我们不会的话，也没啥大事继续往下看就成了。

参考文档：五分钟学习 YML (opens new window)

# github仓库自动创建

进入github指定仓库页面
点击actions
选择基于项目的环境
github会在你的项目根目录下创建.github/workflows/xxx.yml
点击change将会提交到分支上。

# 手动创建yml

在项目的根目录创建.github目录
在.github目录下创建workflows目录
在workflows目录下创建需要执行的自动部署yml文件

# 如何配置yml文件？

在配置yml文件之前，先了解一些基本概念。

# 基本概念

一个yml文件由workflow、job、step、action四部分组成。
workflow(工作流程)：持续集成一次运行的过程，就是一个 workflow。
job(任务)：一个 workflow 由一个或者多个 jobs 构成，含义是一次持续集成的运行，可以完成多个任务。
step(步骤)：每个 job 由多个 step 构成，一步步完成。
action(动作)：每个 step 可以依次执行一个或者多个命令。
每个job的当前行首字母需要对齐, step 和 action 也是。否则会报syntax语法错误。

# 如何定义workflow

Workflow 的名称，Github 在存储库的 Action 页面上显示 Workflow 的名称。如果我们省略 name，则 Github 会将其设置为相对于存储库根目录的工作流文件路径。

name: Greeting from Mona

# 如何定义workflow的触发器

触发 Workflow 执行的 event 名称，比如：每当我提交代码到 Github 上的时候，或者是每当我打 TAG 的时候。

// 单个事件
on: push

// 多个事件
on: [push,pull_request]

# 如何定义一个job?

每个 job 必须具有一个 id 与之关联。
以下的my_first_job和my_second_job就是job_id
配置的name将会显示在Github上

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

# 如何定义job的依赖？job是否可以依赖于别的job的输出？

jobs.<job_id>.needs
needs可以表示job是否依赖于别的job-如果job失败，则会跳过所有需要该job的job。

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

# 如何定义 job 的运行环境?

job.<job_id>.runs-on
指定运行job的虚拟机系统
Github上可用的系统有: - windows-2019 - ubuntu-20.04 - ubuntu-18.04 - ubuntu-16.04 - macos-10.15

jobs:
  job1:
    runs-on: macos-10.15
  job2:
    runs-on: windows-2019

# 如何定义 step

commands: 命令行命令
setup tasks: 环境配置命令（比如安装个Node环境、安装个Python环境）
action: 执行动作

# 定义 Workflow 的名字
name: Greeting from Mona

# 定义 Workflow 的触发器
on: push

# 定义 Workflow 的 job
jobs:
  # 定义 job 的 id
  my-job:
    # 定义 job 的 name
    name: My Job
    # 定义 job 的运行环境
    runs-on: ubuntu-latest
    # 定义 job 的运行步骤
    steps:
    # 定义 step 的名称
    - name: Print a greeting
      # 定义 step 的环境变量
      env:
        MY_VAR: Hi there! My name is
        FIRST_NAME: Mona
        MIDDLE_NAME: The
        LAST_NAME: Octocat
      # 运行指令：输出环境变量
      run: |
        echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.