简介
嗨，我是 WcaleNieWolny - Capgo 的首席软件工程师。
过去 8 个月，我一直在开发 组织系统，截至 4 月 14 日，我很高兴地宣布该系统已完成 🎉 🎊
终于，经过 8 个月的努力，Capgo 的每个部分现在都对组织成员开放。这包括：
- 应用
- 统计
- 账单
- 完整的 CLI 支持
- 还有更多！
走到这一步并不容易，系统经历了三次重大重构。
组织 v1
起步很艰难……我加入项目两周后就开始做这个功能。 当时我对代码库几乎一无所知，对如何实现也没有太大把握。
结果只能实现一个最 hacky 的方案，仅支持访问应用、渠道和版本。 甚至不允许被邀请的用户查看统计数据。
然后我等着 Martin 审查代码。等啊等，却没什么动静。三个月后，我决定回来处理所有合并冲突。我还决定进行测试，事实证明这是个很棒的主意。 不出所料，那个 hacky 方案彻底失败了。那一刻，我决定修复所有 bug 并编写详尽的 E2E 测试。 我不得不与非常破碎的 code 以及过去自己做出的许多糟糕决定打交道，但经过两周的艰苦工作，我终于让它跑起来了。
但这并不意味着它是完美的。组织所有者仍然拥有比最高权限的受邀用户更多的访问权限。用户体验也相当欠缺。受邀用户甚至无法查看应用统计信息、管理账单，且 CLI 仅限于上传。
尽管面临所有这些挑战，Martin 还是审查了 PR，一周后它就被推送到生产环境了。
组织 v2
尽管面临诸多挑战，这套组织系统运行得还算不错。用户们都在使用它，它确实推动了整个项目向前发展。不过，我仍然需要：
- 修复在 行级安全
- 中添加对完整 CLI 的支持
- 确保管理员用户拥有与所有者相同的访问权限
在 大量的讨论 我和 Martin 决定，最好的推进方式是重写全部安全规则，并把所有资源的所有权从用户转到组织。这样能更轻松地集成新的组织系统，也能移除大量遗留的 code。
编写新的 RLS code 非常繁琐，但一周半后，整个迁移就准备好了。
不过这次，我们决定不写 E2E 测试，这意味着只能手动测试。一起开了三次非常长的电话会后，Martin 和我最终决定推上生产环境，希望一切顺利 🙏
结果并没有……原来是我把用户注册搞坏了，导致新用户无法创建账号 😅
匆忙开了个紧急电话会后，我赶紧往生产环境推了一些改动就去睡了。不幸的是，这些改动只带来了更多问题 😰
醒来后，我发现用户那边有很多空组织。这本来不该发生，因为每个用户只应允许有 1 个组织。我们花了一些时间头脑风暴，才删掉所有重复的空组织，但除此之外，变更过程还算顺利。
组织 v3
即便如此也还不够。还缺一个巨大的组件——计费。
此前只有所有者能管理账单。这导致了一些有趣的问题：用户以为自己在为组织购买套餐，结果却买成了个人版。我们很快手动修复了这个问题，并意识到这种情况绝不能容忍。
迁移过程相当顺利。虽然花了一周时间，但相比 V1 和 V2 的迁移，这次真的不算太难 🚀
组织 v4 - 未来方向
经历了这些艰苦的工作后，我觉得现在该把精力转向其他事情了 😎
过程并不容易，但我学到了很多，capgo 也获得了一个非常重要且出色的功能。 我还需要弃用旧版函数、优化 Web 应用的用户体验并监控潜在 bug， 但这个系统应该不会再有重大改动了。
感谢阅读 🚀
继续阅读：全新的组织系统
如果你正在使用 全新的组织系统 要规划 dashboard 和 API 操作，请将其连接到 API 概览 关于 API Overview 中的实现细节， 简介 关于 Introduction 中的实现细节， API 密钥 有关 API Keys 的实现细节， 设备 有关 Devices 的实现细节，以及 Bundle 有关 Bundles 中的实现细节。
