本文转自公号：Pipeline

前言

近一两年游戏工业化的话题时常被提起， 当初在影视行业的时候也是如此。比如最近 鬼猫猫写的游戏工业化系列就讲的十分不错
今天我们来聊聊，跟游戏工业化也有关系的TA们该如何协作开发。我自己亲身经历过的一些实践心得，在我们开始正式内容之前，我想先讲下我以前待过的公司（影视视效）的TD们，是如何协作的。
为了方便叙述，我们下文都简称我以前待过的公司（影视视效）为BM。
本人正好也经历了BM从pipeline 1.0 到 pipeline 2.0的迭代过程。
在2015年我刚加入BM的时候，那时候我们全球的代码还是通过SVN去同步的，然后北京这边会定期拉取SVN去获取代码更新，那时我们有6家分部的代码都在这个SVN上面，也没有什么分支的概念，导致经常代码冲突或者代码更新不及时出现生产被中断的现象。那时候全球的PipelineTD们彼此也没有什么交流，都是通过邮件。大概在2017的时候，我们全球pipeline有一次重大的更新，弃用了SVN转为使用GitLab去管理我们的代码，通过使用Rez去管理我们的软件包。为了方便沟通，我们部署了开源的即时通讯软件Rocket.Chat。全球所有的pipelineTD开始正式协作开发起来了。为了保证代码的可持续维护性和稳定性，我们每次代码更新迭代都会有代码审查环节，比如我写的工具是跟3d相关的，则会找有同样3d开发背景的TD去审查我的代码。审查内容的目的主要为了减少后续我们协作开发的阻碍，一般会检查代码风格，相关文档以及注释，还有代码的单元测试覆盖测试等。
在创建Merge Request的时候，CI/CD会自动帮我们运行代码风格检查还有单元测试，自动化的帮我们发现问题



所有的工具都是通过开源的包管理系统Rez去管理的，所有的服务都在Kubernetes上面部署做到了pipeline as code, config as code, everything as code.我见证了BM在蒙特利尔开设新分部的时候，当IT设置好所有的网络服务器后，pipelineTD们只需要在我们的全局配置中添加新分部的相关配置后，即可同步我们现有的所有工具。这种模式十分适合公司跨时区多分部的运作，可以让全球的TD都联合一起协作开发, 这样工具和流程才会有所沉淀，以全球的体量和技术储备才能迎接未来更大型的项目。
当我从影视行业转到游戏行业，加入游戏行业成为了一名TA时，苦恼于学引擎，学写材质，学C++......在实际工作了一段时间后却发现，游戏这边还没有比较成熟的工具发布与部署流程，基本都是通过SVN， P4V，甚至聊天软件直接发工具。
经常会遇到因为工具更新不及时或者美术同学不会安装对应工具而导致的一些生产问题，同时，我在与组内同事协作开发工具中，也遇到了一些关于python第三方包部署的冲突问题，我就开始着手搭建类似我们以前公司的那种开发模式

• Gitlab 代码管理
• CI/CD 单元测试，持续部署，保证工具的稳定行
• Rez 解决包之间的部署与环境管理
• Sentry 错误日志上报，工具出错我们第一时间能收到错误警报，根据对应的错误log快速定位问题
  

也感谢我们之前组内同事们的信任，配合与支持，最后这套流程还是带来了不小的收益。

• 工具无感知部署与更新，美术不需要自己安装工具插件
• 工具可配置化，可以根据不同组的需求配置我们的工具
• 软件中心化部署，像Houdini和Blender这样的软件都是纯中心部署，美术同学本地不需要安装这些软件，通过我们的工具架启动即可使用
• 工具开发效率和迭代速度明显提升
• 成为了美术与程序之间的桥梁
• 整个项目组的工具部署变得十分容易，美术，程序，策划，PM，QA等都从中受益
  

半年后因为家庭缘故离开了这家公司，

希望我当初搭建的那套框架后面可以越来越好。

以下工具推荐源于我个人的工作经验

不代表行业最终解决方案

工具推荐

Rez （软件的集成包配置、构建和部署系统）

开源于2012，现在已经加入了学院软件基金会，下图是学院软件基金协会的项目以及成员。

更多精彩图片 请登录

Rez已经是一套相当成熟得解决方案了，我们以前公司BM从pipeline1.0到2.0的迁移的时候，还包括了代码python-2到python-3，windows到linux的支持。一共也就花了3年多的时间，而我们全球pipelineTD也就30人左右上下浮动，这些人中还包含很多项目支持的ShowTD

（ShowTD主要是负责项目上的工具需求）

它能帮我们解决我们在部署工具遇到很多问题
比如：

更多精彩图片 请登录

GitLab （企业版本）

更多精彩图片 请登录

GitLab想必大家多少有所了解，推荐使用企业版本，它的CI/CD十分好用相关参考

• https://about.gitlab.com
• https://www.cnblogs.com/cjsblog/p/12256843.html
• https://docs.gitlab.com/ee/ci/
  
  

Sentry (跨平台的应用程序监控，专注于错误报告）

更多精彩图片 请登录

其他行业用的比较多，游戏行业貌似前端会用到，在美术生产工具链这块好像还没有什么人用，但是它真的很好用，让你们团队能及时发现问题，不需要再找美术重现bug、错误日志截图提单，它本身有很多插件和良好的API可以给我们打通各种提单系统，比如Jira, TAPD等。
相关参考

• https://github.com/getsentry/sentry
  

kubernetes （生产级别的容器编排系统）

更多精彩图片 请登录

无论是本地测试，还是跨国公司，Kubernetes 的灵活性都能让你在应对复杂系统时得心应手。Kubernetes 是开源系统，可以自由地部署在企业内部，私有云、混合云或公有云，让您轻松地做出合适的选择。我们组现在所有的服务都是通过CI/CD部署到内部私有云的kubernetes集群上
相关参考

• https://www.redhat.com/zh/topics/containers/kubernetes-architecture
• https://jimmysong.io/kubernetes-handbook/
  

Opentelemetry (便携式遥测技术，以实现有效的可观测性）

更多精彩图片 请登录

Opentelemetry也是近几年在云原生里的一个热议话题，虽然它主要应用在云原生的云服务上，但是它有丰富的SDK，我们可以把它用到DCC相关工具中，做到各种性能指标，使用日志的收集，生成各种可视化的数据方便后续的分析
相关参考：

• https://jimmysong.io/opentelemetry-obervability/history.html
  

更多精彩图片 请登录

协作开发的建议

编写可读性强的Git提交消息

更多精彩图片 请登录

编写可读性强的git提交消息也是十分重要的，能方便我们在多人协作的时候清楚明了的知道我们的每一次迭代，这里我会推荐我现在常用的commitizen这个工具去辅助我们提交代码，

更多精彩图片 请登录

这个工具还有命令可以根据git提交消息生成CHANGELOG.md

更多精彩图片 请登录

相关参考

• https://cbea.ms/git-commit/
• https://github.com/commitizen-tools/commitizen
  

善用logging记录工具中所发生的事情

更多精彩图片 请登录

良好的日志可以帮我们做数据分析，提高我们的工具的质量，我在现在的团队中编写了一个公用的logging API, 可以帮我们把工具的使用日志都记录到数据库，前端网页去显示我们工具的用量等， 这个API会在工具遇到任何错误的时候自动上报到Sentry, 并且发送警报消息到各专项的开发小组群里面，及时让相应的开发者知晓
相关参考https://www.loggly.com/ultimate- ... -logging-traps.html

选定一套代码风格为标准并且实施

在组内开发大家可以商定一套统一的代码风格为标准，在写代码的时候统一风格，减少代码的阅读成本和维护成本，同时可以配套一些工具辅助我们开发。现阶段我们利用tox为基础，集成了pre-commit, black, pylint, flask8,等开源工具，去更加方便的规范我们的代码，降低大家的学习成本。

更多精彩图片 请登录

相关参考

• https://www.runoob.com/w3cnote/google-python-styleguide.html
• https://tox.wiki/en/latest/
  

语义化版本

语义化版本控制，可以让协作者们从版本号中清楚的知道我们发布的版本所代表的含义，是一个bugfix还是添加了一个新的功能
相关参考

• https://semver.org/lang/zh-CN/
  

单元测试

单元测试可帮助您更早地发现和修复错误。将单元测试纳入其开发过程并在生命周期中尽早开始测试的组织能够更早地检测和修复问题。单元测试有助于提高代码质量。这个项目是前一个项目的自然结果。由于单元测试充当安全网，因此开发人员在更改代码时变得更有信心。他们可以重构代码而不必担心会破坏代码，从而提高代码库的总体质量。单元测试可以作为文档。单元测试是如何使用被测代码的示例。因此，您也可以将它们视为可执行的规范或文档。
我们也会引用类似hypothesis这样的自动化测试框架去自动帮我们生成一些单元测试用例，去减少我们的开发时间
相关参考

• https://www.testim.io/blog/unit-testing-best-practices/
• https://insights.dice.com/2022/05/23/python-unit-testing-best-practices-to-follow/
  

更多精彩图片 请登录

结语

以Rez为包管理，利用CI/CD持续部署，组内协作开发的模式，
我已经在俩家游戏公司都已经验证过了，方案是可行。但是会有一些学习成本，如果你的团队信任和配合你，半年左右就能看到不小的收益。起码现在我们现在开发一个新工具会十分方便，工具自动创建好代码仓库并且设置好CI/CD与仓库权限，开发者通过git拉取代码，进入到tox的虚拟开发环境通过tox命令一键创建rez包的基础手脚架可以通过tox命令去运行多版本的单元测试等。
再次感谢所有帮助过我的同事和朋友们，谢谢你们的理解与配合多沟通和分享也是协作开发环节中很重要的一环希望以上内容对大家有所启发，也欢迎大家有好的经验留意或者私信与我交流。

由于本文中包含很多外链，大家可以点击阅读原文，跳转到语雀版本，阅读体验会更佳


全文完公众号地址:https://www.element3ds.com/forum.php?mod=viewthread&tid=448493&ctid=11623

本文转自公号：Pipeline

前言

近一两年游戏工业化的话题时常被提起， 当初在影视行业的时候也是如此。比如最近 鬼猫猫写的游戏工业化系列就讲的十分不错
今天我们来聊聊，跟游戏工业化也有关系的TA们该如何协作开发。我自己亲身经历过的一些实践心得，在我们开始正式内容之前，我想先讲下我以前待过的公司（影视视效）的TD们，是如何协作的。
为了方便叙述，我们下文都简称我以前待过的公司（影视视效）为BM。
本人正好也经历了BM从pipeline 1.0 到 pipeline 2.0的迭代过程。
在2015年我刚加入BM的时候，那时候我们全球的代码还是通过SVN去同步的，然后北京这边会定期拉取SVN去获取代码更新，那时我们有6家分部的代码都在这个SVN上面，也没有什么分支的概念，导致经常代码冲突或者代码更新不及时出现生产被中断的现象。那时候全球的PipelineTD们彼此也没有什么交流，都是通过邮件。大概在2017的时候，我们全球pipeline有一次重大的更新，弃用了SVN转为使用GitLab去管理我们的代码，通过使用Rez去管理我们的软件包。为了方便沟通，我们部署了开源的即时通讯软件Rocket.Chat。全球所有的pipelineTD开始正式协作开发起来了。为了保证代码的可持续维护性和稳定性，我们每次代码更新迭代都会有代码审查环节，比如我写的工具是跟3d相关的，则会找有同样3d开发背景的TD去审查我的代码。审查内容的目的主要为了减少后续我们协作开发的阻碍，一般会检查代码风格，相关文档以及注释，还有代码的单元测试覆盖测试等。
在创建Merge Request的时候，CI/CD会自动帮我们运行代码风格检查还有单元测试，自动化的帮我们发现问题



所有的工具都是通过开源的包管理系统Rez去管理的，所有的服务都在Kubernetes上面部署做到了pipeline as code, config as code, everything as code.我见证了BM在蒙特利尔开设新分部的时候，当IT设置好所有的网络服务器后，pipelineTD们只需要在我们的全局配置中添加新分部的相关配置后，即可同步我们现有的所有工具。这种模式十分适合公司跨时区多分部的运作，可以让全球的TD都联合一起协作开发, 这样工具和流程才会有所沉淀，以全球的体量和技术储备才能迎接未来更大型的项目。
当我从影视行业转到游戏行业，加入游戏行业成为了一名TA时，苦恼于学引擎，学写材质，学C++......在实际工作了一段时间后却发现，游戏这边还没有比较成熟的工具发布与部署流程，基本都是通过SVN， P4V，甚至聊天软件直接发工具。
经常会遇到因为工具更新不及时或者美术同学不会安装对应工具而导致的一些生产问题，同时，我在与组内同事协作开发工具中，也遇到了一些关于python第三方包部署的冲突问题，我就开始着手搭建类似我们以前公司的那种开发模式

• Gitlab 代码管理
• CI/CD 单元测试，持续部署，保证工具的稳定行
• Rez 解决包之间的部署与环境管理
• Sentry 错误日志上报，工具出错我们第一时间能收到错误警报，根据对应的错误log快速定位问题
  

也感谢我们之前组内同事们的信任，配合与支持，最后这套流程还是带来了不小的收益。

• 工具无感知部署与更新，美术不需要自己安装工具插件
• 工具可配置化，可以根据不同组的需求配置我们的工具
• 软件中心化部署，像Houdini和Blender这样的软件都是纯中心部署，美术同学本地不需要安装这些软件，通过我们的工具架启动即可使用
• 工具开发效率和迭代速度明显提升
• 成为了美术与程序之间的桥梁
• 整个项目组的工具部署变得十分容易，美术，程序，策划，PM，QA等都从中受益
  

半年后因为家庭缘故离开了这家公司，

希望我当初搭建的那套框架后面可以越来越好。

以下工具推荐源于我个人的工作经验

不代表行业最终解决方案

工具推荐

Rez （软件的集成包配置、构建和部署系统）

开源于2012，现在已经加入了学院软件基金会，下图是学院软件基金协会的项目以及成员。

更多精彩图片 请登录

Rez已经是一套相当成熟得解决方案了，我们以前公司BM从pipeline1.0到2.0的迁移的时候，还包括了代码python-2到python-3，windows到linux的支持。一共也就花了3年多的时间，而我们全球pipelineTD也就30人左右上下浮动，这些人中还包含很多项目支持的ShowTD

（ShowTD主要是负责项目上的工具需求）

它能帮我们解决我们在部署工具遇到很多问题
比如：

更多精彩图片 请登录

GitLab （企业版本）

更多精彩图片 请登录

GitLab想必大家多少有所了解，推荐使用企业版本，它的CI/CD十分好用相关参考

• https://about.gitlab.com
• https://www.cnblogs.com/cjsblog/p/12256843.html
• https://docs.gitlab.com/ee/ci/
  
  

Sentry (跨平台的应用程序监控，专注于错误报告）

更多精彩图片 请登录

其他行业用的比较多，游戏行业貌似前端会用到，在美术生产工具链这块好像还没有什么人用，但是它真的很好用，让你们团队能及时发现问题，不需要再找美术重现bug、错误日志截图提单，它本身有很多插件和良好的API可以给我们打通各种提单系统，比如Jira, TAPD等。
相关参考

• https://github.com/getsentry/sentry
  

kubernetes （生产级别的容器编排系统）

更多精彩图片 请登录

无论是本地测试，还是跨国公司，Kubernetes 的灵活性都能让你在应对复杂系统时得心应手。Kubernetes 是开源系统，可以自由地部署在企业内部，私有云、混合云或公有云，让您轻松地做出合适的选择。我们组现在所有的服务都是通过CI/CD部署到内部私有云的kubernetes集群上
相关参考

• https://www.redhat.com/zh/topics/containers/kubernetes-architecture
• https://jimmysong.io/kubernetes-handbook/
  

Opentelemetry (便携式遥测技术，以实现有效的可观测性）

更多精彩图片 请登录

Opentelemetry也是近几年在云原生里的一个热议话题，虽然它主要应用在云原生的云服务上，但是它有丰富的SDK，我们可以把它用到DCC相关工具中，做到各种性能指标，使用日志的收集，生成各种可视化的数据方便后续的分析
相关参考：

• https://jimmysong.io/opentelemetry-obervability/history.html
  

更多精彩图片 请登录

协作开发的建议

编写可读性强的Git提交消息

更多精彩图片 请登录

编写可读性强的git提交消息也是十分重要的，能方便我们在多人协作的时候清楚明了的知道我们的每一次迭代，这里我会推荐我现在常用的commitizen这个工具去辅助我们提交代码，

更多精彩图片 请登录

这个工具还有命令可以根据git提交消息生成CHANGELOG.md

更多精彩图片 请登录

相关参考

• https://cbea.ms/git-commit/
• https://github.com/commitizen-tools/commitizen
  

善用logging记录工具中所发生的事情

更多精彩图片 请登录

良好的日志可以帮我们做数据分析，提高我们的工具的质量，我在现在的团队中编写了一个公用的logging API, 可以帮我们把工具的使用日志都记录到数据库，前端网页去显示我们工具的用量等， 这个API会在工具遇到任何错误的时候自动上报到Sentry, 并且发送警报消息到各专项的开发小组群里面，及时让相应的开发者知晓
相关参考https://www.loggly.com/ultimate- ... -logging-traps.html

选定一套代码风格为标准并且实施

在组内开发大家可以商定一套统一的代码风格为标准，在写代码的时候统一风格，减少代码的阅读成本和维护成本，同时可以配套一些工具辅助我们开发。现阶段我们利用tox为基础，集成了pre-commit, black, pylint, flask8,等开源工具，去更加方便的规范我们的代码，降低大家的学习成本。

更多精彩图片 请登录

相关参考

• https://www.runoob.com/w3cnote/google-python-styleguide.html
• https://tox.wiki/en/latest/
  

语义化版本

语义化版本控制，可以让协作者们从版本号中清楚的知道我们发布的版本所代表的含义，是一个bugfix还是添加了一个新的功能
相关参考

• https://semver.org/lang/zh-CN/
  

单元测试

单元测试可帮助您更早地发现和修复错误。将单元测试纳入其开发过程并在生命周期中尽早开始测试的组织能够更早地检测和修复问题。单元测试有助于提高代码质量。这个项目是前一个项目的自然结果。由于单元测试充当安全网，因此开发人员在更改代码时变得更有信心。他们可以重构代码而不必担心会破坏代码，从而提高代码库的总体质量。单元测试可以作为文档。单元测试是如何使用被测代码的示例。因此，您也可以将它们视为可执行的规范或文档。
我们也会引用类似hypothesis这样的自动化测试框架去自动帮我们生成一些单元测试用例，去减少我们的开发时间
相关参考

• https://www.testim.io/blog/unit-testing-best-practices/
• https://insights.dice.com/2022/05/23/python-unit-testing-best-practices-to-follow/
  

更多精彩图片 请登录

结语

以Rez为包管理，利用CI/CD持续部署，组内协作开发的模式，
我已经在俩家游戏公司都已经验证过了，方案是可行。但是会有一些学习成本，如果你的团队信任和配合你，半年左右就能看到不小的收益。起码现在我们现在开发一个新工具会十分方便，工具自动创建好代码仓库并且设置好CI/CD与仓库权限，开发者通过git拉取代码，进入到tox的虚拟开发环境通过tox命令一键创建rez包的基础手脚架可以通过tox命令去运行多版本的单元测试等。
再次感谢所有帮助过我的同事和朋友们，谢谢你们的理解与配合多沟通和分享也是协作开发环节中很重要的一环希望以上内容对大家有所启发，也欢迎大家有好的经验留意或者私信与我交流。

由于本文中包含很多外链，大家可以点击阅读原文，跳转到语雀版本，阅读体验会更佳


全文完公众号地址:https://www.element3ds.com/forum.php?mod=viewthread&tid=448493&ctid=11623