最近，Spotify 移动工程团队详细介绍了他们最近的平台迁移经验。根据移动工程战略计划，该团队将他们的 Android 和 iOS 代码库迁移到了谷歌的开源构建系统 Bazel 上。
来自 Spotify 移动工程团队的 Mariana Ardoino 和 Raul Herbster 在一篇博客文章中探讨了从迁移中获得的经验教训。迁移工作影响了 Spotify 的 100 多个团队。团队认识到，不同规模和复杂性的迁移将成为未来的“常态”，因此该团队通过强调定义迁移范围的必要性来设定上下文。
通常，当迁移的范围未知时，关注价值并理解迁移的目标是有意义的。该团队建议从概念验证 (POC) 入手，并与利益相关者一起验证，而不是在一开始就确定所有可能的场景。通过这些早期阶段与利益相关者的合作，对了解涉众对迁移的需求也是有用的。
当有大量的团队受到影响并且进度缓慢时，大规模的基础设施和架构更改似乎是不可能的。这样的情况需要利益相关者更大程度的参与。通过 Slack/ 电子邮件组与利益相关者保持联系，并通过通讯和工作场所的帖子分享进展，可以再次强调迁移的重要性。在迁移过程中，寻找自动化的可能性可能会有所帮助。为研究高峰预留时间也是一个不错的选择，其中可以包括与团队一起进行迁移。
另一方面，Puppet 的首席技术官 Nigel Kersten 强调了敏捷（Agile）/DevOps 转型背景下的协作，他说：
从根本上讲，问题在于所有这些转变都包含了大量的人际互动成分，而你作为一个组织，你的规模越大、历史越长，改变人际互动方式就越困难，你必须要去到更高的链条上来创造组织变革。
Spotify 移动工程团队提到，对于参与迁移的任何平台团队来说，相互竞争的优先级都是“现实”。无论迁移是否涉及采用新技术还是减少技术债，团队的动机水平都可能因迁移进展缓慢而受到影响。团队建议持续评估迁移进度，通过展示迁移的积极影响来激励团队，并调整方法以实现某些迁移目标。
最后，在讨论问责制方面，Spotify 移动工程团队建议，不要期望在一段时间内推动变革的内部 / 外部一致性。使用仪表板、维护迁移时间表以及使用数据或趋势图可能有助于可视化进度并突出显示所需的调整。
原文链接：
https://www.infoq.com/news/2022/12/spotify-plat-migration-lessons/
声明：本文为 InfoQ 翻译，未经许可禁止转载。
从 polyrepo 到 monorepo，前端代码仓库改造工程实践
Google 路线图：Flutter 与 JavaScript、Wasm 集成