使用GitHub Actions与ArgoCD搭建CICD流水线平台

背景

之前断断续续接触过CICD这些概念，但是使用的不多，并且相关概念比较模糊，这里通过GitHub Actions和Argo CD打造一个CICD平台，来熟悉相关概念和流程。

CI(Continuous Integration) 持续集成

平时完成一个需求的时候，一般会做一些测试，比如单元测试,e2e测试等等，完成这些测试之后再去提交代码到不同的分支。之后等待其他人来review代码在合并。

从静态分析到测试，可以通过makefile来完成一个半自动化的过程，但是当涉及到多人协作的时候，makefile就不够用了。比如每个人的开发环境是不一样的，有时候需要依赖第三方库，像Linux就有不同的发行版，比如centos,ubuntu等等，还要考虑Windows情况。虽然可以通过docker来解决环境一致性问题，但是在资源利用率上又是一个问题。

这个时候引入CI可以解决之前提到的问题:

1. 环境一致性问题
2. 资源利用率问题

这里，开发人员完成需求通过git提交代码到代码仓库(github/gitlab)之后，触发CI流程，也就是之前提到过的静态分析，构建，测试等步骤，其中有一个环节出现错误就会停止下来，之后发送结果给开发者。

CD(Continuous Delivery / Continuous Deployment)持续交付/持持续部署

我对CD的理解更倾向于持续部署(continuous Deployment)，但是它还有一个概念是持续交付(Continuous Delivery)。

这是redhat里面关于CD的流程图，两者表示自动化不同的程序，持续交付表示代码在经过更新修改之后，提交到代码仓库之后或者镜像仓库，再通过运维团队部署到生成环境中。

持续部署自动化程度更高，通过所有测试之后，自动部署到生产环境，但是缺少运维团队审核，导致错误在生产环境上发生。前面的CI和code view只能发现大部分问题，涉及到生产需要谨慎在谨慎。

总结一下就是:

触发方式：

• 持续交付： 部署需要手动触发，需要人工干预。
• 持续部署： 部署是自动触发的，无需人工干预。

发布时机：

• 持续交付： 代码随时可以部署到生产环境，但需要人为选择时机。
• 持续部署： 每次通过测试的代码都会自动部署到生产环境。

适用场景：

• 持续交付： 适用于对发布时机有一定控制要求，需要人工审批的环境。
• 持续部署： 适用于追求更快速、频繁交付的环境，希望最大程度自动化的场景。

流水线

实战

这里以一个Go程序为例子，通过CICD流程最后在k8s集群上运行。使用Actions中关于Go CI

# This workflow will build a golang project
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-go

name: Go

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:

  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Set up Go
      uses: actions/setup-go@v4
      with:
        go-version: '1.20'

    - name: Build
      run: go build -v ./...

    - name: Test
      run: go test -v ./...