Introduction
Salut, je suis WcaleNieWolny - Capgo's lead ingénieur logiciel.
Sur les 8 derniers mois, j'ai développé le context: Page/area: Capgo Builder / native cloud build product page. Role: Short UI label or navigation item. Message key `native_build_builder_credit_over` (Native Build Builder Credit Over).système d'organisation
Finally, after 8 months, every single part of Capgo is accessible to org members. This includes:
- Enfin, après 8 mois, chaque partie de __CAPGO_KEEP_0__ est accessible aux membres de l'organisation. Cela inclut :
- applications
- statistiques
- factures et éclairages sur CLI
- et encore bien plus !
Il n'a pas été facile d'arriver là; il y a eu 3 grandes révisions du système.
Organisations v1
Les débuts ont été difficiles… J'ai commencé à travailler sur ce projet 2 semaines après avoir rejoint l'équipe. À l'époque, j'avais peu de connaissances sur le codebase ou aucune idée plus large sur la manière d'implémenter cela.
Cela a conduit à l'implémentation d'une solution très hackeuse qui ne supportait que l'accès aux applications, aux canaux et aux versions. Elle ne permettait même pas aux utilisateurs invités d'accéder aux statistiques.
Et puis j'ai attendu que Martin révise cela. J'ai attendu et attendu, mais rien n'est vraiment arrivé. 3 mois plus tard, j'ai décidé de revenir sur cela et de résoudre tous les conflits de fusion. J'ai également décidé de tester, ce qui s'est avéré être une excellente idée. Comme prévu, la solution hackeuse a complètement échoué. À ce moment-là, j'ai décidé de corriger tous les bugs et d'écrire des tests E2E exhaustifs. J'ai dû travailler avec des code très cassés et de nombreuses mauvaises décisions que j'avais prises à l'époque, mais après 2 semaines difficiles, j'ai finalement réussi à le faire fonctionner.
Cela ne signifie pas, cependant, que cela était parfait. Le propriétaire de l'organisation avait encore beaucoup plus d'accès que même l'utilisateur invité le plus élevé. L'expérience utilisateur était également très limitée. L'utilisateur invité ne pouvait même pas voir les statistiques des applications, gérer les factures et le CLI était limité à l'upload uniquement.
Malgré tous ces défis, Martin avait révisé le PR, et une semaine plus tard, il a été poussé en prod.
Organisations v2
Le système d'organisation fonctionnait plutôt bien malgré tous les défis. Les utilisateurs l'utilisaient, et cela a vraiment poussé l'ensemble du projet en avant. Cependant, j'avais encore à :
- corriger le désordre créé dans la sécurité au niveau de ligne
- ajouter le support pour l'ensemble de CLI
- assurer que les utilisateurs administrateurs aient les mêmes accès que le propriétaire
Après beaucoup de discussions avec Martin, nous avons décidé que la meilleure façon de poursuivre était de réécrire les règles de sécurité entières et de déplacer la propriété de tous les ressources vers les organisations et non les utilisateurs. Cela permettrait une intégration plus facile avec le nouveau système d'organisation, et cela supprimerait également un grand nombre de legacy code.
Écrire les nouvelles RLS code était très fastidieux, mais après une semaine et demie, la migration entière était prête.
Cette fois-ci, nous avons décidé de ne pas écrire les tests E2E, ce qui signifie que nous devions les tester manuellement. Après 3 appels très étendus ensemble, Martin et moi avons finalement décidé de pousser vers la production et d'espérer qu'il irait bien 🤖
Ce n'est pas allé… Il s'avère que j'avais cassé l'enregistrement des utilisateurs, et les nouveaux utilisateurs ne pouvaient pas créer un compte 😬
Après un appel de panique rapide, j'ai rapidement poussé quelques modifications dans prod et suis allé me coucher. Malheureusement, mes modifications n'ont créé que plus de problèmes 😜
Après avoir ouvert les yeux, j'ai découvert que les utilisateurs avaient beaucoup d'organisations vides. Cela ne devait pas se produire car il ne devait y avoir qu'une organisation par utilisateur. Il a fallu du temps de réflexion pour supprimer toutes les organisations dupliquées et vides, mais en dehors de cela, les changements se sont plutôt bien passés.
Organisations v3
Même cela n'était pas suffisant. Il manquait encore un grand composant - la facturation.
Jusqu'à présent, seul le propriétaire pouvait gérer la facturation. Cela a créé des problèmes intéressants où un utilisateur a acheté un plan en pensant qu'il l'achetait pour l'organisation.
Nous avons rapidement résolu le problème manuellement et c'est à ce moment-là que nous avons décidé que ce problème était inacceptable.
La migration s'est plutôt bien passée. Il a fallu une semaine de travail mais comparé à V1 et V2, cela n'était vraiment pas si dur 🏠
Organisations v4 - l'avenir
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.
Cela n'a pas été facile mais j'ai appris beaucoup et __CAPGO_KEEP_0__ a reçu une très belle et importante fonctionnalité Je dois encore dépréciquer les fonctions légacière, améliorer l'expérience utilisateur de l'application web, surveiller les bogues, mais il ne devrait pas y avoir de changements majeurs à ce système.
Merci de lire 🏠
Continuez de A un nouveau système d'organisation Si vous utilisez un nouveau système d'organisation pour planifier le tableau de bord et les API opérations, connectez-l’à API Vue d'ensemble pour les détails d'implémentation dans API Vue d'ensemble, Introduction pour les détails d'implémentation dans Introduction, API Clés pour les détails d'implémentation dans API Clés, Appareils pour les détails d'implémentation dans Appareils, et Ensembles pour les détails d'implémentation dans Ensembles.
