不同机器jenkins环境部署规范
- 系统环境保持一致,如用户名、ssh登录配置均保持一致。
- 约定统一的jenkins版本,因为每个版本的xml序列化格可能不一致。
- 环境变量进行统一约定,并且由git进行统一的管理。
- job的配置由git进行统一的管理,方便不同机器进行同步。
- job的工作空间路径保持一致,不一致的尽量使用软链进行保持。
- 要保持同步的文件夹尽量使用软链进行替代。
- unity工程按不同平台进行区分,防止平台切换造成耗时。
- unity工程尽量分为代码仓与资源仓,资源仓通过软链由不同平台共用【可减少磁盘占用】。
…
jenkins打包调用历程
- jenkins设置参数的会自动同步到环境变量。
- 代码仓、资源仓、模板仓、python工具仓均进行git重置。
- 调用python进行环境变量重设(同时可以传入命令行参数对环境变量参数进行覆写)。
- python执行unity命令行。
- unity启动进行初始化,并从环境变量内获取必须的数据。
- unity导出android或者xcode工程,暂且称为临时工程。
- python在临时工程提取变动部分同步到模板工程内。
- 根据环境变量对模板工程进行配置。
- 对模板工程进行编译生成apk或者ipa。
- python统计生成包的信息并同步到约定的目录。
- 对代码仓进行tag提交上传。
- end。
jenkins打资源调用历程
- jenkins设置参数的会自动同步到环境变量。
- 代码仓、资源仓、资源池仓均进行git重置。
- 执行unity命令行。
- unity启动进行初始化,并从环境变量内获取必须的数据。
- unity打包代码执行。
- 资源池仓变动部分进行git提交上传。
- end。
jenkin资源上传历程
- jenkins设置参数的会自动同步到环境变量。
- python获取本地目录文件列表。
- python获取远程目录文件列表。
- 列举出本地目录与远程目录文件差量列表。
- python进行差量文件上传。
补充:unity资源打bundle思路
接口BuildPipeline.BuildAssetBundles我们暂且称为接口A
- 调用接口A前统计bundle生成目录文件【最后写入时间】信息形成老字典。
- 调用接口A进行bundle更新。
- 调用接口A后统计bundle生成目录文件【最后写入时间】信息形成新字典。
- 找出新字典与老字典形成差量字典,差量字典为本次资源的更新列表。
- 枚举差量字典进行对应的文件名称转换,文件名称为内容hash。
Q&A
【Q1】打包为什么使用模板工程而不是使用临时工程?
- unity的OnPostprocessBuild后处理并不能处理所有的情况,例如在针对xcode处理时,有些库或资源并不一定可以很方便的加上去(并不是所有的sdk库与资源都会符合规范)。
- 模板工程一旦固定,可长期不动,不受unity自身的变化影响。
- 使用模板工程可以实现不同分支进行不同sdk的管理。
- sdk的升级更加方便。
- 可实现unity一次导出,模板工程多次编译【例如更改服务器,切换sdk等】。
【Q2】Unity2019与Unity2018导出的xcode工程的区别及优缺点?
- 区别:unity2019的xcode工程中,unity部分是一个名称为【UnityFramework】动态库。
- 缺点:主target可编译的前提是UnityFramework这个库要编译成功,而UnityFramework编译成功的前提是sdk所需库与引用必不可少,这个对于sdk的剥离与管理非常之不友好。
- 优点:可方便的集成到原生xcode工程中,但我们的项目不需要。