部署自动打包环境

概述

• 基于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
  

参考资料：

• https://docs.gitlab.com/runner/
• https://docs.gitlab.com/ce/ci/yaml/