发布时间由平均 5 分钟减少到 1.5 分钟。从全程 5 分钟的手动操作,到只需合并分支代码、自动化构建及发布的 1.5 分钟。
前端构建放到 CI/CD 中,解决了本地构建可能导致线上代码打包后不一致的问题。
开发完成后,在本地进行 build,build 后提交打包后的 HTML 文件。
打开发布系统,发布 HTML 文件。
发布代码的操作流程长,耗时。开发完成后,发布代码时,需要经过大量的手动操作,加上发布系统慢,每次发布大约需要 5 分钟。
每个人本地环境不一致,线上代码不同的人发布有不一致的风险。
执行 build 命令,等待 build 完成。
build 完成后,提交打包后的 HTML 文件。
打开发布系统
选择发布项目及环境
打开发布页面
选择发布文件
填写发布信息
点击确认发布
登录 GitLab:https://gitlab.com/
新建一个自己的项目
拉取项目到本地
在项目根目录新建 .gitlab-ci.yml 文件
提交 .gitlab-ci.yml 文件
在项目的 CI/CD 中,可以看到 CI/CD 的运行情况
image: node
# 定义 stages
stages:
- build
- test
# 定义 job
build 阶段:
stage: build
script:
- echo "build stage"
# 定义 job
发布到测试环境:
stage: test
script:
- echo "test stage"
新建 GitLab 项目
配置 GitLab Runner
.gitlab-ci.yml 文件
下载 GitLab Runner
注册 GitLab Runner
使用 GitLab Runner
Shared Runners
Specific Runners
Group Runners
下载依赖阶段 pre_build
构建阶段 build
发布阶段 deploy
stage 申明当前的阶段,在 stages 中使用
variables 用于定义变量
before_script 执行 script 前的操作
script 当前 stage 需要执行的操作
changes 指定 stage 触发条件
refs 指定 stage 触发的分支
variables:
# $CI_PROJECT_PATH :项目id,用于项目唯一区分本项目与其它项目
# $CI_PROJECT_DIR :本地项目路径
# $PROCESS_PATH :临时文件目录(包括日志和一些临时文件)
NODE_MODULES_PATH: /runner-cache/frontend/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME/node_modules
stages:
- pre_build
- build
- deploy
下载依赖:
before_script:
# 无 node_modules 文件时,新建 node_modules 文件
- /bin/bash ./ci/mkdir.sh $NODE_MODULES_PATH
# 软链 node_modules 到宿主机
- ln -s $NODE_MODULES_PATH .
- cd webpack@next
stage: pre_build
script:
- echo "yarn install"
- yarn install --network-timeout 60000
only:
changes:
- webpack@next/package.json
refs:
- test
- test-99
- test-128
- master
- ci
- feature/ci-test
构建:
stage: build
variables:
CI_COMMIT_BEFORE_SHA_PATH: /mnt/gv0/gitlab-runner-cache/$CI_PROJECT_PATH
CI_COMMIT_BEFORE_SHA_FILE_NAME: $CI_BUILD_REF_NAME.sh
CI_COMMIT_BEFORE_SHA_FILE: /mnt/gv0/gitlab-runner-cache/$CI_PROJECT_PATH/$CI_BUILD_REF_NAME.sh
before_script:
# 建存此次 CI CI_COMMIT_SHA 的文件
- /bin/bash ./ci/mkfile.sh $CI_COMMIT_BEFORE_SHA_PATH $CI_COMMIT_BEFORE_SHA_FILE_NAME
# 软链 node_modules 到宿主机
- ln -s $NODE_MODULES_PATH .
- rm -rf php/share/*
- cd webpack@next
script:
# 缓存上次ci
- source $CI_COMMIT_BEFORE_SHA_FILE
- echo "CI_COMMIT_BEFORE_SHA=$CI_COMMIT_SHA" > $CI_COMMIT_BEFORE_SHA_FILE
- python3 ../ci/build.py # 编译
- /bin/bash ../ci/commit.sh # 提交编译结果
only:
changes:
- www_src/**/*
refs:
- test
- test-99
- test-128
- master
- ci
测试发布:
stage: deploy
variables:
PROCESS_PATH: /mnt/gv0/gitlab-runner-cache/deploy/process/$CI_JOB_ID # 目录不要换,用于日志服务器获取日志展示
script:
- mkdir $PROCESS_PATH # 建立发布临时路径,存放发布配置中间文件和结果日志用
- dplt $CI_PROJECT_DIR/.deploy_test.yml $CI_PROJECT_PATH $CI_PROJECT_DIR/php/ $PROCESS_PATH
# dplt 发布yml配置
- echo "发布完成,错误日志查看http://new.admin.wolffy.qihoo.net/log?path="$PROCESS_PATH
- echo `ls $PROCESS_PATH/*.log`
only:
changes:
- php/**/*
refs:
- test
diff 文件变化
前端 build
commit build 后结果
对于一个持续集成,虽然实现了自动构建和发布,但缺少关键的测试环节。
借助于 GitLab CI/CD,我们实现了线上环境的一致,但本地开发环境和线上环境仍然不一致,可能存在本地没有问题,线上出现问题的情况。
从 SVN 切到 Git 开发后,分支管理策略,分支命名规范,commit message 规范,CodeReview 等,在团队中需要逐步规范。
https://docs.gitlab.com.cn/runner/
https://docs.gitlab.com/ee/ci/docker/usingdockerbuild.html
https://docs.gitlab.com/ee/ci/yaml/README.html
https://git-scm.com/book/zh/v2/Git-%E5%B7%A5%E5%85%B7-%E5%87%AD%E8%AF%81%E5%AD%98%E5%82%A8