简介
嘿，我是 WcaleNieWolny - Capgo的首席软件工程师。
在过去的8个月里，我一直在开发 上下文：Capgo Builder / 原生云构建产品页面。角色：短UI标签或导航项。消息键`native_build_builder_credit_over`（原生构建构建者信用过）。组织系统
Finally, after 8 months, every single part of Capgo is accessible to org members. This includes:
- 经过8个月的努力，__CAPGO_KEEP_0__的每个部分都可以供组织成员访问。这包括：
- 应用
- 统计
- full CLI support
- 还有很多更多的功能！
经过了3次重大系统修订，才到达这里。
组织v1
开始时，情况很糟糕……我加入这个项目后，仅仅两周就开始工作了。 当时，我对代码库几乎一无所知，也没有更大的想法来实现这个功能。
这导致了只支持访问应用、频道和版本的最hacky解决方案。 甚至不允许被邀请的用户查看统计数据。
然后我等待了Martin的审查，但什么也没发生。3个月后，我决定回到这个问题并解决所有的冲突。同时，我也决定进行测试，这是一个很好的决定。 毫不奇怪，hacky解决方案完全失败了。在那个时候，我决定修复所有的bug并编写一个详尽的E2E测试。 我不得不与非常破碎的code和过去的我做出的很多坏决定一起工作，但经过2个艰难的周，我终于让它正常工作。
这并不意味着它是完美的。组织的拥有者仍然拥有比最高被邀请用户更多的访问权限。用户体验也很糟糕。被邀请的用户甚至无法查看应用统计数据、管理账单和CLI仅限于上传。
尽管存在这些挑战，Martin已经审查了PR，一个星期后它就被推入生产环境。
组织v2
尽管面临各种挑战，组织系统仍然运作得相当好。用户正在使用它，并且它真正推动了整个项目的进展。然而，我仍然需要：
- 修复在 行级安全
- add support for the entire CLI
- 确保管理员用户具有与所有者相同的访问权限
之后 与马丁进行了大量讨论 with Martin, we decided that the best way to move forward was to rewrite the entire security rules and to move all the resource ownership to organizations and not users. This would allow for easier integration with the new organization system, and it would also remove a lot of legacy code.
Writing the new RLS code was very tedious, but after a week and a half, the entire migration was ready.
非常枯燥，但经过一周半的努力，整个迁移就准备好了。
这次，我们决定不编写E2E测试，这意味着我们必须手动测试。经过3次非常详细的电话会议，马丁和我最终决定推送到生产环境并希望它会顺利
它没有… Turns out我破坏了用户注册，新用户无法创建账户
醒来后，我发现用户有很多空的组织。这不是应该发生的事情，因为每个用户只应该允许一个组织。经过一些头脑风暴后，删除所有重复的空组织花了不少时间，但除了那以外，变化还是比较顺利的。
组织 v3
即使如此，还有一个巨大的组件缺失——计费。
目前只有拥有者才能管理计费。这导致了一个有趣的问题：用户购买了一个计划，认为自己是在为组织购买的。 我们快速修复了这个问题，并在此时决定这个问题是不可接受的。
迁移过程相对顺利。花了一个星期的工作，但与 V1 和 V2 相比，它确实不是那么困难 🚀
组织 v4 - 未来
经过了这么多的努力，我想现在是时候专注于其他事情了 😎
这不是容易的，但我学到了很多，capgo 得到了一个非常好的和重要的功能 我仍然需要废弃遗留的函数、改善 Web 应用用户体验、监控 bug，但这个系统应该不会有太大的变化。
感谢您的阅读 🚀
继续阅读 A brand new organization system
如果您正在使用 A brand new organization system 为了规划仪表板和API操作，连接它 API概览 在API概览中了解实现细节 简介 在简介中了解实现细节 API密钥 在API密钥中了解实现细节 设备 在设备中了解实现细节，并且 捆绑包 在捆绑包中了解实现细节。
