新服务入驻生产环境 CICD 全流程、自动化脚本教程

背景

新服务功能完成测试后，将会进行生产环境的入住，对外提供产品、功能支持。那么如何规范的、安全的、自动化的把本地服务移植到生产环境呢/？

这里简单介绍一下，本地服务入住生产环境规范且安全的过程。

CICD

为进行服务价值可持续、高效的敏捷交付，组织往往会引入 CICD 的执行方式。进行 自动化、安全、规范、且高效的服务移植。

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。 CI/CD 的核心概念是持续集成、持续交付和持续部署。

百花齐放

CICD 的实现、执行方式并不唯一，可以说是 more and more 。组织往往会根据自身的研发体系氛围、文化，选择最契合的方式。这里将介绍一个相对规范、稍微复杂的实现方式。

熟悉的同学可通读，感兴趣的可以精度。

“四部曲”实现

“四部曲” 将整个 CICD 过程拆分为 编译、部署两个大阶段，通过四个文件串联起整个流程。

优势

1. 支持本地代码分支自动化触发
2. 支持不同的环境构建：dev、test、diy…等
3. 支持多依赖、跨语言，复杂服务场景： Go 调用 C 动态库 …等
4. 支持 纯净的生产环境，代码无外漏风险，安全有保障

涉及文件

• ci.yml：所属编译阶段，连接 代码库 的桥梁，分支 PUSH 通过执行 ci.yml 触发后续编译流程
  • 根目录：XXX/ci.yml
• Makefile：所属编译阶段，ci.yml 调用文件，执行指定运行命令，编译服务
  • 根目录：XXX/Makefile
• package.sh：所属部署阶段，对依赖配置文件、动态库进行打包
  • 根目录：XXX/package.sh
• noah_control：所属部署阶段，设置运行环境变量、执行指定运行命令，启动、中止、重启服务
  • bin 目录：XXX/bin/noah_control

核心流程

• 代码库 -> ci.yml -> Makefile -> package.sh -> noah_control

ci.yml

参数由 代码库配置 指定，支持多种编译、打包协议。

Global:
  tool : build_submitter

Default:
  profile : [build]

Profiles:
  - profile:
    name : build
    env : XXX
    command : make -f Makefile
    release : True
  - profile:
    name: test
    env: XXX
    command: make -f Makefile test-package conf_dir=test
    release: True

Makefile

设置依赖包拉取环境、对服务进行编译。

#初始化项目目录变量
HOMEDIR := $(shell pwd)
OUTDIR  := $(HOMEDIR)/output
APPNAME = $(shell basename `pwd`)

#初始化命令变量
GOROOT  := $(GO_1_19_HOME)
GO      := $(GOROOT)/bin/go
GOPATH  := $(shell $(GO) env GOPATH)
GOMOD   := $(GO) mod
GOBUILD := $(GO) build

#执行编译，可使用命令 make 或 make all 执行, 顺序执行 prepare -> compile -> test -> package 几个阶段
all: set-build-env prepare compile package

prepare: prepare-dep
prepare-dep:
	git config --global XXX

set-build-env:
	$(GO) env -w CC=XXX/gcc-4.8.2/bin/gcc
	$(GO) env -w CXX=XXX/gcc-4.8.2/bin/g++

set-env:
	$(GO) env -w GONOPROXY=\*\*.XXX\*\*
	$(GO) env -w GOPROXY=http://goproxy.XXX
	$(GO) env -w GONOSUMDB=\*
	$(GO) env -w GO111MODULE=on
	$(GO) env
#complile阶段，执行编译命令,可单独执行命令: make compile
compile:build
build: set-env
	$(GOMOD)  download 
	$(GOBUILD)  -o $(HOMEDIR)/bin

#test阶段，进行单元测试， 可单独执行命令: make test
test: test-case
test-case: set-env
	rm -rf $(OUTDIR)/test
	mkdir -p $(OUTDIR)/test
	
package: package-bin
package-bin:
	sh package.sh $(OUTDIR) online

test-package: set-build-env compile test-package-bin
test-package-bin:
	sh package.sh $(OUTDIR) $(conf_dir)

#clean阶段，清除过程中的输出, 可单独执行命令: make clean
clean:
	rm -rf $(OUTDIR)

package.sh

• 依据服务 ci.yml 配置所属环境变量，进行打包。

#! /usr/bin/env sh

set -e
OUTDIR=$1
CONFNAME=$2
echo "Build Env: " + $2
echo "Output Dir: " + $1

package_online() {
   # 删除重建输除目录
  echo "clear $OUTDIR"
  rm -rf "$OUTDIR"
  mkdir -p "$OUTDIR/output"

   # [重要]拷贝执行文件和 「线上」 环境的配置
  cp -a bin "$OUTDIR/output/bin"
  cp -a conf "$OUTDIR/output/conf"

  cd "$OUTDIR/output" && tar -zcvf "$OUTDIR/output.tar.gz" ./*
  cd ../../

  # 执行过程copy的内容清理, 最终产物是 $OUTDIR/output.tar.gz
  rm -rf "$OUTDIR/output"
}

case "${2}" in
    "online")
        echo "build online package"
        package_online
        echo "build online package done"
    ;;
    *)
        echo "build ${2} package"
        package_test
        echo "build ${2} package done"
    ;;
esac

noah_control

• 通过 nohup 进行服务启动、停止、重启，等服务状态控制。

......可私信博主或关注后续博文

小结

CICD 在实际应用中虽然实现方式，千差万别，但核心功能是同一的。
这里建议在组织中引入 “方便、快捷” 的方式。上述的方式虽然整体可行，在各阶段落地、调试成本、和人智成本相对较高，不建议个人或小规模状态下使用。