部署自动打包环境

2018-11-08 本文已影响0人 Wurq

部署自动打包环境

概述

基于Gitlab-CICD配置的自动打包环境。
在Gitlab上创建Tag时，会执行包含Deploy的CICD操作。
- 创建方法：左侧菜单栏->Repository->Tags->New tag。
- 在Deploy的Job成功后，将会把对应的压缩包发布至指定目录中。

通过Gitlab的打包方式

完整包：创建前缀为'tag_full_'的tag。
- tag_full_win_version: 仅打包win的完整包。
- tag_full_ios_version: 仅打包ios的完整包。
- tag_full_android_version: 仅打包android的完整包。
- tag_full_version: 未指定版本，默认为打包三种版本(win,ios,android)的完整包。
  - 打包三种版本的完整包的tag一般取名为tag_full_all_version。
补丁包：创建前缀'tag_patch_'的tag。
- tag_patch_ios_version: 仅打包ios的补丁包。
- tag_patch_andorid_version: 仅打包android的补丁包。
- tag_patch_version: 未指定版本，默认为打包两种版本(ios和android)的补丁包。
  - 打包两种版本的补丁包的tag一般取名为tag_patch_all_version。

如何创建自动更新的补丁

概述：
- 补丁是基于上一个完整包的版本进行的资源/脚本文件修改。
- 通过补丁包可替换原本完整包中的资源/脚本文件，实现热更新。
自动更新机制：
- 基于指定版本的资源及脚本文件生成MD5的文件记录。
  - md5_assets.txt: 客户端的资源文件的MD5值。
  - md5_lua.txt: 客户端的lua脚本的MD5值。
  - md5_scripts.txt: 客户端的C#脚本的MD5值。(C#脚本无法用于自动更新)
  - patch.json: 记录所修改的资源/脚本文件。
- 通过比较生成的MD5的记录，从而区分哪些文件发生了变化。
生成补丁的详细操作：
- 将项目切换至指定完整包的版本，通过菜单栏->Build->生成AssetBundle完整包。
  - 在生成AB完整包后，确保获取到的MD5文件为获取指定完整包的版本的MD5值。
- 在生成AssetBundle完整包后，可进行资源/脚本文件的修改。
- 在确保资源/脚本文件修改完成后，新增一行版本号，作为补丁版本。
  - 版本号文件：/client/Assets/StreamingAssets/version.txt
  - 一般补丁包的版本号只在原始版本号的基础上，迭代后两位小版本。
- 获取补丁包的MD5文件，通过菜单栏->Build->新增AssetBundle补丁包。
  - 在新增AB补丁包后，获取到补丁包的MD5文件记录。
- 提交补丁包：
  - 将所修改的资源/脚本文件及其补丁包的MD5文件记录提交只版本库上。
  - 通过gitlab创建该分支的tag，tag名称为tag_patch_version。
  - 执行完该tag的CICD后，可在指定目录获取到补丁包。

生成完整包的流程图：

  graph TD
    Build[创建并切换至指定版本的分支]
    FullPackage_MD5[完整包的MD5文件记录 ]
    CurrentBranch_Local[当前分支-本地]
    CurrentBranch_Remote[当前分支-远程]
    PackFull[生成完整包]
    
    subgraph 获取完整包的MD5
      Build
      FullPackage_MD5
      CurrentBranch_Local
      CurrentBranch_Remote
    end
    
    subgraph 获取完整包
      Gitlab
      PackFull
    end
    
    Build -- 生成该版本AB完整包 --> FullPackage_MD5
    FullPackage_MD5 -- 提交完整包的MD5文件 --> CurrentBranch_Local
    CurrentBranch_Local -- Git Sync & Push --> CurrentBranch_Remote
    CurrentBranch_Remote --> Gitlab
    Gitlab -- 通过Gitlab创建当前分支的tag,tag名称前缀为tag_full_ --> PackFull

生成补丁包的流程图：

  graph TD
    Build[创建并切换至指定版本的分支]
    FullPackage_MD5[完整包的MD5文件记录]
    PatchPackage_MD5[补丁包的MD5文件记录]
    CurrentBranch_Local[当前分支-本地]
    CurrentBranch_Remote[当前分支-远程]
    PackPatch[生成补丁包]

    subgraph 获取补丁包的MD5
      Build
      FullPackage_MD5
      PatchPackage_MD5
      CurrentBranch_Local
      CurrentBranch_Remote
    end

    subgraph 获取补丁包
      Gitlab
      PackPatch
    end

    Build --生成该版本AB完整包--> FullPackage_MD5
    FullPackage_MD5 -- 修改资源/脚本文件以及在version.txt中新增版本号 --> PatchPackage_MD5
    PatchPackage_MD5 -- 提交修改的资源/脚本文件以及补丁包的MD5文件 --> CurrentBranch_Local
    CurrentBranch_Local -- Git Sync & Push --> CurrentBranch_Remote
    CurrentBranch_Remote --> Gitlab
    Gitlab -- 通过Gitlab创建当前分支的tag, tag名称前缀为tag_patch_ --> PackPatch

如何搭建Gitlab-CICD的平台

概述：
- CI/CD是指持续集成/持续部署。
  - 持续集成(Continuous integration)是一种软件开发实践，每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。
  - 持续部署（continuous deployment）是通过自动化的构建、测试和部署循环来快速交付高质量的产品。
- 中心思想是当每一次push到gitlab的时候，都会触发一次脚本执行，然后脚本的内容包括了测试，编译，部署等一系列自定义的内容。
CI/CD的好处：
- 快速发现错误。
  - 每完成一点更新，就集成到主干上，可以快速发现错误，定位错误也比较容易。
- 防止分支大幅度偏离主干。
  - 如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
CI/CD中的基本概念:
- Pipeline:
  - Pipeline表示构建任务，包含测试，编译，部署等一系列的阶段的执行。
  - 每次提交都会创建一条Pipeline。
- Stages:
  - Stages表示构建阶段，属于Pipeline的组成单元。
  - Stages的特点为：
    - 当前Stages都执行成功，才会执行下一个Stages。
    - 所有的Stages都执行成功，该pipeline才会成功。
  - 一般将Stages分为三个阶段：build，test，deploy。
- Jobs:
  - Jobs表示构建工作，属于Stages的组成单元。
  - Jobs的特点为：
    - 每个Stages中的所有Job执行成功，该Stages才会执行成功。
    - 默认情况下，每个Job都是单独的环境，每个job直接不互相干扰。
      - 如果存在job之间相互依赖，则可以通过artifacts或cache实现。
      - 具体实现通过.gitlab.yml实现：https://docs.gitlab.com/ce/ci/yaml/README.html
- Gitlab-CI：
  - Gitlab自带的持续集成系统，.gitlab.yml的脚本解析就由它来负责。
- Gitlab-Runner：
  - 负责.gitlab.yml脚本的部分执行，.gitlab.yml的script部分的运行就是由runner来负责的。
  - Gitlab-CI通过解析.gitlab.yml文件后，根据里面的规则，分配对应的runner执行相应脚本script。
    - 每个runner都有自己的一个tag，作为向Gitlab注册的标签，Gitlab-CI可根据该tag执行指定runner。
  - 一台服务器/pc可以注册多个Runner，要让Runner同时运行，则需要进一步参考官方文档
- .gitlab.yml：
  - 必须存在与git项目的根目录下的一个文件, 记录了一系列的执行阶段和执行规则。
- Pipeline流程图:
```
  graph LR
    check1{是否全部成功}
    check2{是否全部成功}

    Job_build1 --> check1
    Job_build2 --> check1
    check1 --> Job_test1
    check1 --> Job_test2
    Job_test1 --> check2
    Job_test2 --> check2
    check2 --> Job_deploy1
    check2 --> Job_deploy2
    subgraph States1
    Job_build1
    Job_build2
    end

    subgraph States2
    Job_test1
    Job_test2
    end

    subgraph States3
    Job_deploy1
    Job_deploy2
    end
```
- Gitlab-CI/CD流程图：
```
  graph LR
    Gitlab-CI[Gitlab-ci->解析.gitlab.yml]
    
    subgraph 服务器/PC3
    RunnerN
    end

    subgraph 服务器/PC2
    Runner2
    end

    subgraph 服务器/PC1
    Runner1
    end

    Developer -- push --> Gitlab
    Gitlab --> Gitlab-CI
    Gitlab-CI --tag1--> Runner1
    Gitlab-CI --tag2--> Runner2
    Gitlab-CI --tagN--> RunnerN
```

注册Gitlab-Runner:

基于已搭建好的Gitlab，注册Runner来实现CI/CD。
准备工作：
- 下载Gitlab-Runner：
  - 下载地址：https://docs.gitlab.com/runner/install/index.html
  - Gitlab-Runner的版本号 <= Gtilab的版本号。
- 获取Gitlab上项目的管理员权限，打开左侧菜单栏->Setting->CI/CD->Runner。
  - 在Specific Runners获取Gitlab的URL和Token。
- 如果gitlab为https链接，则需要获取Gitlab的公钥证书：
  - 打开浏览器，点击网址框左侧的锁图标。
  - 切换至下一页，点击更多信息。
  - 在弹出的页面信息框->安全->网站身份->查看证书。
  - 在弹出的证书查看器->详细信息->导出。
  - 获取到该gitlab.crt。

开始注册：

打开命令行执行:

    gitlab-runner-windows-amd64.exe register ^
    --non-interactive ^
    --name win7_test_2 ^
    --tag-list win7_test_2 ^
    --url https://m68gitlab.g-bits.com/ ^
    --registration-token CAsBb_m2cRzzBMnNJeJx ^
    --executor shell ^
    --tls-ca-file ./m68gitlab.g-bits.com.crt

上述命令选项含义(*为必选项)：

  --non-interactive       非交互式
  --name                  该Special Runner服务名，便于后台管理（查看、删除、调用）*
  --tag-list              该Special Runner标签，集成脚本中可以通过指定tag关联
  --url                   Gitlab的地址*
  --registration-token    项目里刚才看到的token，互相关联的标志*
  --excutor               规定集成脚本执行的环境，还可以是shell，docker等*

注册成功后，可在项目的Setting->CI/CD->Runner中查看到新注册的Runner信息。

运行Gitlab-Runner：
- 打开命令行执行：
```
  gitlab-runner-windows-amd64.exe run
```
注册Gitlab-runner服务：
- 即开机自动通过System账号运行Gitlab-runner。
- 注册Gitlab-runner服务，默认的服务名为gitlab-runner。
  - 想要在同一台PC上注册多个Gitlab-runner服务，需要自定义服务名。
    - 自定义服务名的方式：--service name
- 打开命令行执行：(需要使用管理员身份执行)
```
  gitlab-runner-windows-amd64.exe install 
  或
  gitlab-runner-windows-amd64.exe install --user name --password pw
```
- Runner服务管理相关指令：
```
  gitlab-runner-windows-amd64.exe start     // 开启服务
  gitlab-runner-windows-amd64.exe stop      // 停止服务
  gitlab-runner-windows-amd64.exe uninstall // 卸载服务
```

Gitlab-Runner流程图：

  graph LR
    PC[服务器/PC]
    Developer -- 获取gitlab的公钥证书,URL,Token --> PC
    PC -- 注册Runner --> Gitlab
    PC -- 运行Runner --> Gitlab
    Gitlab -- 通知执行 --> Gitlab-CI

配置.gitlab.yml文件
- 基本模板：
```
  stages:
    - test
    - deploy

  win_test:
      script:
          - echo win_test
          - call test.bat
      stage: test
      tags:
          - win7_test

  win_deploy:
      script:
          - echo win_deploy
          - call deploy.bat
      stage: deploy
      tags:
          - win7_test
```
- 上述主要参数：
  - states：
    - 构建阶段，自定义要执行的几个阶段。
  - win_test，win_deploy:
    - 构建工作，具体要执行的内容。
    - script：
      - 该job所要执行的命令行指令。
    - stage：
      - 限定该job属于哪一个stages。
    - tags：
      - 限定该job执行的脚本是在哪一个Runner上执行。
- 测试命令,检验语法:
  - 可在 GitLab->CI/CD->Pipelines->CI Lint 中进行执行。
- 测试命令,检验语法:
  - 可在 GitLab->CI/CD->Pipelines->CI Lint 中进行执行。
- 返回值获取
  - 通过在批处理中，获取运行脚本的返回值。errorlevel指令。
  - 从而，判断是否exit 0 或者exit -1。实现样例是否通过的判断。
- GitLab-CI中的cache和artifacts的区别
  - 用Docker运行Gitlab-Runner，cache会生成一些临时容器，不容易清理。
  - cache不一定能够命中，artifacts肯定命中。
  - cache与机器上Runner缓存的容量相关。
    - 能否使用cache取决于机器是否生成过cache，artifacts则每次都能从Gitlab下载。
    - artifacts中定义的部分，会自动生成，并可以传到下面的job中解压使用，避免了重复依赖安装等功能。
    - artifacts可以设置自动过期时间, 过期自动删除，cache不会自动清理。
    - artifacts会先传到GitLab服务器, 然后需要时再重新下载, 所以这部分也可以在GitLab下载和浏览。
    - artifacts在jobs成功时才会将指定文件上传至Gitlab。

自动打包环境的流程图：

  graph LR
    Developer -- 通过Gitlab创建完整包/补丁包的tag --> Gitlab-CI
    Gitlab-CI -- 解析.gitlab.yml执行命令行指令 --> 执行打包操作

  graph TD
    pack[执行打包操作]
    pack_full[执行打完整包操作]
    pack_patch[执行打补丁包操作]
    packing_full[执行指定版本的打完整包操作]
    packing_patch[执行指定版本的打补丁包操作]
    packing_full_all[执行所有版本android,ios,win的打完整包操作]
    packing_patch_all[执行所有版本android,ios的打补丁包操作]
    transform_package[传输压缩包文件至指定目录]
    check_tag_pre{识别tag名称}
    check_tag_full{tag名称是包含android/ios/win}
    check_tag_patch{tag名称是包含android/ios}

    pack --> check_tag_pre
    check_tag_pre -- tag名称前缀为tag_full_ --> pack_full
    check_tag_pre -- tag名称前缀为tag_patch_ --> pack_patch

    pack_full --> check_tag_full
    pack_patch --> check_tag_patch

    check_tag_full -- 是 --> packing_full
    check_tag_full -- 否 --> packing_full_all
    check_tag_patch -- 是 --> packing_patch
    check_tag_patch -- 否 --> packing_patch_all

    packing_full --> transform_package
    packing_patch --> transform_package
    packing_full_all --> transform_package
    packing_patch_all --> transform_package

部署自动打包环境

部署自动打包环境

概述

通过Gitlab的打包方式

如何创建自动更新的补丁

如何搭建Gitlab-CICD的平台

参考资料：

猜你喜欢

热点阅读