工作流

通过软件开发的持续方法,您可以持续构建、测试和部署迭代代码更改。这种迭代过程有助于减少您基于有缺陷或失败的先前版本开发新代码的机会。 使用这种方法,您可以努力减少从开发新代码到部署的人工干预,甚至根本不需要干预。
持续方法的三种主要方式是:
- 持续集成
- 持续交付
- 持续部署
每一家 CICD 产品,都有各自的配置方式,但是总体上用法差不多。
Runner: 用来执行 CI/CD 的构建服务器workflow/pipeline: CI/CD 的工作流。(在大部分 CI,如 GitLab 中为 Pipeline,而 GitHub 中为 Workflow,但二者实际上还是略有不同)job: 任务,比如构建,测试和部署。每个 workflow/pipeline 由多个 job 组成
我们假设一个极其简单的 Git Workflow 场景。
- 每个人在功能分支进行新功能开发,分支名
feature-*。每一个功能分支将会有一个功能分支的测试环境地址,如<branch>.dev.shanyue.tech。 - 当功能分支测试完毕没有问题后,合并至主分支
master。在主分支将会部署到生产环境。 - 当生产环境出现问题时,切出一条分支
hotfix-*,解决紧急 Bug。
工作流

你在本地开发好一个新功能后提交到远程仓库后。提交后自动触发 CI/CD,自动执行脚本(串行或并行)
- 构建并测试你的应用
- 在预览应用程序中预览更改,就像你在本地主机上看到的一样。
实现的功能能如预期工作后
- 审查和批准您的代码
- 将 feature 分支合并到默认分支中。
- CI/CD 自动将更改部署到生产环境中。
构建服务器与部署服务器
个人学习和使用中构建服务器和部署服务器通常为同一个服务器,而在工作中,二者往往为独立服务器。但是为了更好的 CICD,构建服务器会赋予控制部署服务集群的权限,在构建服务器中通过一条命令,即可将某个服务在部署服务器集群中进行管理。
- 部署服务器: 对外提供服务的服务器,容器在该服务器中启动。
- 构建服务器: 进行 CI 构建的服务器,一般用以构建、测试和部署,构建镜像以及自动部署服务。一般也可以是 Docker 容器。
在 CICD 中,构建服务器往往会做以下工作,这也是接下来几篇篇章的内容:
- 功能分支提交后,通过 CICD 进行自动化测试、语法检查、npm 库风险审计等前端质量保障工程,如未通过 CICD,则无法 Code Review,更无法合并到生产环境分支进行上线
- 功能分支提交后,通过 CICD 对当前分支代码构建独立镜像并生成独立的分支环境地址进行测试如对每一个功能分支生成一个可供测试的地址,一般是
<branch>.dev.shanyue.tech此种地址 - 功能分支测试通过后,合并到主分支,自动构建镜像并部署到生成环境中 (一般生成环境需要手动触发、自动部署)