jenkins事项备注

不同机器jenkins环境部署规范

• 系统环境保持一致，如用户名、ssh登录配置均保持一致。
• 约定统一的jenkins版本，因为每个版本的xml序列化格可能不一致。
• 环境变量进行统一约定，并且由git进行统一的管理。
• job的配置由git进行统一的管理，方便不同机器进行同步。
• job的工作空间路径保持一致，不一致的尽量使用软链进行保持。
• 要保持同步的文件夹尽量使用软链进行替代。
• unity工程按不同平台进行区分，防止平台切换造成耗时。
• unity工程尽量分为代码仓与资源仓，资源仓通过软链由不同平台共用【可减少磁盘占用】。
  …

jenkins打包调用历程

1. jenkins设置参数的会自动同步到环境变量。
2. 代码仓、资源仓、模板仓、python工具仓均进行git重置。
3. 调用python进行环境变量重设（同时可以传入命令行参数对环境变量参数进行覆写）。
4. python执行unity命令行。
5. unity启动进行初始化，并从环境变量内获取必须的数据。
6. unity导出android或者xcode工程，暂且称为临时工程。
7. python在临时工程提取变动部分同步到模板工程内。
8. 根据环境变量对模板工程进行配置。
9. 对模板工程进行编译生成apk或者ipa。
10. python统计生成包的信息并同步到约定的目录。
11. 对代码仓进行tag提交上传。
12. end。

jenkins打资源调用历程

1. jenkins设置参数的会自动同步到环境变量。
2. 代码仓、资源仓、资源池仓均进行git重置。
3. 执行unity命令行。
4. unity启动进行初始化，并从环境变量内获取必须的数据。
5. unity打包代码执行。
6. 资源池仓变动部分进行git提交上传。
7. end。

jenkin资源上传历程

1. jenkins设置参数的会自动同步到环境变量。
2. python获取本地目录文件列表。
3. python获取远程目录文件列表。
4. 列举出本地目录与远程目录文件差量列表。
5. python进行差量文件上传。

补充：unity资源打bundle思路

接口BuildPipeline.BuildAssetBundles我们暂且称为接口A

1. 调用接口A前统计bundle生成目录文件【最后写入时间】信息形成老字典。
2. 调用接口A进行bundle更新。
3. 调用接口A后统计bundle生成目录文件【最后写入时间】信息形成新字典。
4. 找出新字典与老字典形成差量字典，差量字典为本次资源的更新列表。
5. 枚举差量字典进行对应的文件名称转换，文件名称为内容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工程中，但我们的项目不需要。