2024.09.14

发表于 更新于 分类于 阅读次数： 本文字数： 794 阅读时长 ≈ 3 分钟
Sat | 八月十二 | 甲辰癸酉辛巳

今天下大雨，找到的共享单车比较难骑 ￣へ￣，骑车到公司花了40多分钟

Seasun day4

Narrate

download file 17.2GB -> 160S

ToDo

知识点

  • Linux 链接目录

工作内容

  • bvt 长期归档落地

早上来很快就完成了 MechaServer 和 RoomServer 的归档。

zilve 跟测试核对之后，还是需要服务器相关的 il2cpp 和 符号文件一起归档。

了解了命名规则之后很快做了提交。

  • 需求交付

    • 流水线使用：执行时直接把客户端bvt下载链接作为参数（因为周四的bvt有时候也会失败，所以测试同学根据实际情况进行归档即可），流水线即可归档客户端和服务器相关的文件到 ftp 共享目录中
    • 执行情况：目前4分中内，可以归档所需文件，总计 20GB
    • 执行反馈：成功和失败都会通知执行人
    • 共享使用：1）需要开通 ip 白名单才可以访问共享文件

2）下载速度：17.2GB 需要160s，速度约为 110MB/s

上午完成了bvt归档，下午做另一个需求任务。

  • AB包构建缓存清理

zilve 讲述了一下 asset bundle 相关的术语，我以虚幻引擎相关的术语与其做了沟通验证，统一了术语方便日常沟通。

zilve 同时讲述了相关的构建机集群任务分配规则，以及针对某一台构建机内项目做了简述说明。

zilve 特意嘱托不要轻易删除构建机文件目录，一定 review 再操作。

看了一下午主干版本构建流水线的子任务逻辑，以及 Library 相关的流水线，大致梳理了一下 Library 的流转过程，对 Library 任务做了简单的解读分析

任务解读

背景

着重说明 Library 的生死流转。

每次构建都会涉及 unity builder 的构建流程，里面对于 Library 的处理是：

位于 **201**** 机器上

1
move   cache-Library   to   Proj-Library

unity 构建完成之后，处理逻辑如下：

1
2
move   Proj-Library   to   cache-Library
将 Library.7z 上传文件服务器

这是构建过程中的逻辑。

清理逻辑：

**200**** 机器上重新生成 Library，然后流转：

1
move   Proj-Library   to   cache-Library

将生成的内容移动到缓存文件夹

再将缓存文件夹内容 压缩成 Library.7z，然后流转：

1
将 200 机器中生成的 Library.7z 上传至 189 机器

此过程需要 **3h**** 左右

然后 **201**** 机器将 **189**** 机器中的 Library 压缩包下载替换本地的 cache-library

下次版本包构建即可将全新生成过的 cache-library 用于构建。

需求

每次重新生成耗时很久，只需要把处理BundleCache对应的目录（Library\BuildCache\）即可

未完待续

今天简单梳理了一下过程，但是看的还不全面，Library的流入流出可能还有遗漏，后续跟 zilve 核对之后再继续做。

下周继续加油！