概要
Hey, 私は WcaleNieWolny - Capgoのリードソフトウェアエンジニアです。
過去8ヶ月間で、組織システムの開発を実施してきました。 そして、2023年4月14日現在、システムは完成しました 🎉 🎊 ようやく8ヶ月後、__CAPGO_KEEP_0__の全ての機能は組織メンバーにアクセス可能になりました。これには含まれます。アプリ
Finally, after 8 months, every single part of Capgo is accessible to org members. This includes:
- 請求
- 完全な__CAPGO_KEEP_0__サポート
- organization system
- Finally, after 8 months, every single part of CLI is accessible to org members. This includes:
- そしてさらに多くの機能があります!
ここまで来るには、システムの3つの大きな改訂が必要でした。
組織v1
このプロジェクトに参加してから2週間でこの作業を始めました。時点では、コードベースや実装方法についての理解はほとんどありませんでした。
その結果、最もハック的な解決策を実装し、しかもアプリ、チャネル、バージョンのみをサポートするものでした。招待されたユーザーは、統計情報を参照することもできませんでした。
And then I waited for Martin to review this. I waited and waited, but nothing really happened. 3 months later, I decided to come back to this and fix all the merge conflicts. I also decided to test, which turned out to be a great idea. To no surprise, the hacky solution completely failed. At that moment, I decided to fix all bugs and write an extensive E2E test. I had to work with very broken code and a lot of bad decisions made by the past me, but after 2 hard weeks, I finally got it to function.
That does not, however, mean that it was perfect. The owner of the organization still had a lot more access than even the highest invited user. User experience also was quite lacking. The invited user could not even see the application statistics, manage billing, and the CLI was limited to upload only.
過去の私が残した、非常に壊れた__CAPGO_KEEP_0__と、多くの悪い決定を伴う作業でしたが、2週間の厳しい作業の後、ようやく機能するようになりました。
しかし、それでも完璧ではありませんでした。組織のオーナーは、招待されたユーザーよりも多くのアクセス権を持っており、ユーザー体験も非常に不足していました。招待されたユーザーは、統計情報を参照することも、請求管理を行うこともできませんでした。__CAPGO_KEEP_0__は、ファイルのアップロードのみが可能でした。
組織システムは、すべての課題にもかかわらず、うまく機能していました。ユーザーはそれを使用し、プロジェクト全体を前進させました。しかし、まだ:
- 行レベルセキュリティ 全体の__CAPGO_KEEP_0__に対するサポートを追加する
- 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.
新しいRLScodeを書くことはとても面倒だったが、半分の週で全ての移行が完了した。
しかし、今回はE2Eテストを書くことに反対したため、手動でテストする必要があった。
マーティンと私は3回の非常に詳細な電話会議をし、最終的にプロダクションにプッシュし、うまくいくことを願った。
しかし、うまくいかなかった…ユーザー登録が壊れ、新規ユーザーはアカウントを作成できなかった。
起きてから、ユーザーが多くの空の組織を持っていることを発見した。1つの組織だけが許可されるはずなので、これは起こるべきではない。組織の重複削除に時間がかかったが、変更は比較的順調だった。
組織 v3
それでも十分ではなかった。課金機能が大幅に不足していた。
現在、課金機能はオーナーだけが管理できていた。ユーザーが組織の課金を購入したと誤解した問題が生じた。
手動で問題を解決し、ここでこの問題は受け入れられないと判断した。
マイグレーションは比較的順調だった。V1とV2と比べると、1週間の作業で済んだ。
組織 v4 - 未来
It was not easy but I learned a lot and capgo has received a very nice and important feature I still have to deprecate the legacy functions, improve the webapp user experience, monitor for bugs, but there should not be any major changes to this system.
これは難しかったが、__CAPGO_KEEP_0__ に重要で素晴らしい機能が追加された。
まだ、古い機能を非推奨にし、Webアプリのユーザー体験を向上させ、バグを監視する必要があるが、このシステムに大きな変更は行わないだろう。
読んでくれてありがとう。 A から始めて新しい組織システムを続けよう。 ダッシュボードとAPIの運用計画を立てるには、 APIの概要 APIの概要の実装詳細については 導入 導入の実装詳細については APIのキー APIのキーについての実装詳細 デバイス デバイスについての実装詳細 バンドル バンドルについての実装詳細
