في سلسلة منشورات المدونة هذه، يتحدث إلينا Valentin De Almeida، أحد مطوري Ledger Live، حول تطور قاعدة بيانات Ledger Live على مر السنين. في منشور المدونة هذا، ستتعلم أنه كان يعتمد على مستودعات متعددة في البداية، والمشكلات التي واجهناها على طول الطريق، وسبب الحاجة إلى التطور إلى بنية مستودع أحادي. في منشورات المدونة التالية، سنشرح كيفية إجراء مشروع الهجرة الرئيسي هذا.
قليلا من التاريخ
وكان نمو ليدجر في عامي 2020 و2021 كبيراً. لقد قمنا بتوظيف مواهب جديدة بقوة، ووسعنا فريقنا من مجرد مجموعة قليلة إلى أكثر من 20 مطورًا. وهذا يعني أن الكثير من المهندسين الجدد قد انضموا إلى المشاريع القائمة. ومع النمو السريع لفريقنا، واجهنا تحديات جديدة كان علينا معالجتها بسرعة. على الرغم من هذه الصعوبات الجديدة، بقينا نركز على هدفنا واستمرنا في تقديم عمل استثنائي.
لقد أخذنا خطوة إلى الوراء ونظرنا في المشكلات الجديدة التي تنشأ عندما ينضم المزيد والمزيد من الأشخاص إلى المشروع. ومن بين تلك التحديات الجديدة، يمكننا أن ندرج الاحتياجات التالية:
- تدفقات أبسط.
- إرشادات أفضل للمساهمين الوافدين والخارجيين.
- مجموعة موحدة من الأدوات.
- إدارة التبعية بشكل أفضل.
- مساهمات مركزية مفتوحة المصدر.
حالة الفن: قبل الهجرة
في البداية، وحتى العام الماضي، كان Ledger Live يعتمد على بنية متعددة المستودعات، لكل من الواجهات الأمامية للهواتف المحمولة وسطح المكتب، بالإضافة إلى كل المنطق الكامن وراءها. لم يكن العمل بهذه الطريقة قرارًا واعيًا، ولكنه كان فقط نتيجة لمشروع موسع بدون قيادة معمارية حقيقية. Ledger Live هو مشروع يجمع مكونات مختلفة في عنصر واحد لتقديم التطبيق الأفضل والأكثر أمانًا لمستخدمي Nano لدينا، وقد انعكس ذلك في قاعدة التعليمات البرمجية.
كانت التدفقات التي قمنا بها غير مستقرة في أحسن الأحوال، ويرجع ذلك في الغالب إلى حقيقة أننا كنا 6 أو 7 مطورين قبل عامين. وبما أن عدد الأطراف المشاركة كان أقل، كان التواصل أسهل بكثير وأفلتنا من العقاب. ومع ذلك، كانت هناك بعض نقاط الضعف في الطريقة التي كنا نعمل بها، خاصة فيما يتعلق بتجربة المطورين وعملية الإصدار.
اختناقات تجربة التطوير
تبعيات
نظرًا لطبيعة مشاريعنا، فإننا نعمل على مستودعات متعددة في نفس الوقت، مع وجود تبعيات بينها. هنا لمحة سريعة:
يتم استخدام مكتبات Ledger مفتوحة المصدر بواسطة منطق الأعمال، والذي يتم استخدامه بعد ذلك بواسطة كل من تطبيقات سطح المكتب والجوال. لكن هذه التطبيقات تستخدم أيضًا المكتبات مفتوحة المصدر، وتستخدم نسختين مختلفتين من نفس المكتبة (مثل @ledgerhq/errors على سبيل المثال) من شأنه أن يعطل التطبيق.
كنا بحاجة إلى رفع الإصدار من جانب واحد، ثم نشر المكتبات (نعم، إلى npm!!!)، ثم حاول مرة أخرى إذا لم ينجح الأمر. بدأنا الاعتماد على yalc لربط المشاريع، وهو أمر كان مقبولًا في الغالب طالما لم يكن لدينا عدة طبقات من التبعيات (على سبيل المثال، من المكتبات مفتوحة المصدر إلى منطق الأعمال، ثم من منطق الأعمال إلى التطبيقات). لقد حاولنا مبدئيًا العمل معه yarn link أيضًا، ولكن يبدو أن الأمر محكوم عليه بالفشل مع React Native.
الاختبار
كان من المستحيل تقريبًا إجراء اختبارات التكامل مع أحدث التعليمات البرمجية من المشاريع المختلفة. نظرًا لأننا كنا بحاجة إلى نشر المكتبات في السجل، فقد كان اختبار كافة المكونات باستخدام أحدث التعليمات البرمجية بمثابة كابوس
كان علينا أيضًا الحفاظ على العديد من CI بمنطق مكرر.
تبديل السياق
إن التنقل دائمًا بين العديد من محرري الأكواد / المشاريع / الدلائل جعل تجربة التطوير تبدو ضعيفة حقًا.
تحرير اختناقات العملية
الإصدارات
يعد التعامل مع إصدارات المشاريع المختلفة أمرًا صعبًا، خاصة عندما يكون هناك عدة طبقات من التبعيات.
إطلاق
كان تتبع الإصدار معقدًا نظرًا لتقسيم المشاريع، وكان علينا إدارة إصدارات المشاريع المختلفة
كان من المستحيل أتمتة عملية الإصدار، ويرجع ذلك مرة أخرى إلى حقيقة تقسيم المشاريع إلى مستودعات مختلفة.
وبطبيعة الحال، كان التسليم المستمر غير وارد في هذه المرحلة.
حل ممكن ؟
إذا نظرنا حولنا بحثًا عن الإلهام، يبدو أن بنية المستودع الأحادي هي القطعة المركزية التي كنا نفتقدها. ومن شأنه أن يتيح عملية تطوير أفضل بكثير. توجد أدوات مبنية حول هذه البنية من شأنها أن تساعدنا في تحقيق الأجزاء المفقودة (الإصدار، والأتمتة، وإصدار الإصدارات...).
ولكن، ما هو المستودع الأحادي؟
المستودع الأحادي في جوهره هو مشروع يضم جميع المشاريع الأخرى ذات الصلة (التطبيقات والمكتبات والأدوات) ضمن مشروع مجلد / git واحد. فهو يسمح بإدارة التبعية بشكل أفضل، وتوحيد الأدوات (مثل أنماط التعليمات البرمجية وتكوينات الآلة الكاتبة)، والتكامل المستمر المركزي، واختبار التكامل، والإصدار الموحد من الحزم المستخدمة (الرد على سبيل المثال)...
نظرًا لأنه نظام حيادي جدًا، فقد تُركت لنا بعض الميزات لاكتشافها وتنفيذها. نأمل أن تكون هناك بعض أدوات المجتمع الرائعة التي يمكن أن تساعدنا في إضافة التنسيق إلى الإصدارات (الإصدارات المتسلسلة، المفيدة لـ CI)، وإصدار الإصدارات، وإنشاء سجل التغيير.. والتي من شأنها إكمال ما كنا نفتقده في عملية الإصدار لدينا.
سلبيات
تكون المستودعات الأحادية منطقية في سياق يعمل فيه العديد من المطورين أو فريق من المطورين على عدة مشاريع في نفس الوقت، مع وجود تبعيات فيما بينهم. ومع ذلك، فإنه يضيف طبقة من التعقيد أثناء مرحلة الإعداد (خاصة مع المشاريع القائمة بالفعل والتي قيد التشغيل والتي لها 4 سنوات من التاريخ والتطوير النشط). ومن الجدير بالذكر أن المشروع أصبح أكبر بكثير (مثل أكبر بكثير) من حيث مساحة القرص. جميع المشاريع موجودة الآن ضمن نفس المجلد وجميع التبعيات. ما هي الاختبارات الإلزامية؟ متى تثيرهم؟
الايجابيات
وبعد تقييم الوقت والتكلفة وجدوى طموحاتنا، إليك بعض الفوائد المتوقعة من هذا التحول:
- تحسين إدارة التبعيات: مع monorepo، من الأسهل إدارة التبعيات بين المشاريع المختلفة، حيث يتم تخزينها جميعًا في نفس المستودع. يمكن أن يقلل هذا من الحاجة إلى حلول بديلة مثل رابط الغزل أو
yalc، وتسهيل التأكد من أن جميع المشاريع تستخدم الإصدارات الصحيحة من التبعيات. - تنظيم أفضل للتعليمات البرمجية: يمكن أن يسهل monorepo تنظيم التعليمات البرمجية، حيث يتم تخزين جميع المشاريع وتبعياتها في مستودع واحد. من الأسهل أن نفهم كيف تتلاءم المشاريع المختلفة معًا وكيف تعتمد على بعضها البعض.
- تجربة مطور محسنة: يمكن لـ monorepo أن يسهل على المطورين العمل على مشاريع متعددة، حيث أنهم لا يحتاجون إلى التبديل بين قواعد التعليمات البرمجية أو المستودعات المختلفة. ويمكنه أيضًا تسهيل إجراء اختبارات التكامل، حيث يتم تخزين كافة التعليمات البرمجية في نفس المستودع.
- أتمتة محسنة وتسليم مستمر: مع monorepo، من الأسهل أتمتة المهام مثل إنشاء التعليمات البرمجية واختبارها وإصدارها. يمكن أن يساعد ذلك في تبسيط عملية الإصدار وتسهيل تنفيذ التسليم المستمر.
- زيادة سرعة التطوير. نظرًا لأن الفرق المختلفة تعمل في نفس المستودع، فلن يحتاجوا إلى الانتظار حتى الإصدار للتحقق من النتيجة، مما يؤدي إلى تسريع عملية التكامل.
وفي الختام
بشكل عام، يمكن أن يساعد تنفيذ هيكل monorepo في تحسين عملية التطوير، وتبسيط عملية الإصدار، وتعزيز تجربة المطور.
في منشورات المدونة التالية من هذه السلسلة، سنوجهك عبر كيفية إجراء مشروع الترحيل الرئيسي هذا، والأدوات التي استخدمناها، والاختيارات التي قمنا بها، والنتيجة والمزيد. ترقبوا الجزء الثاني: الأدوات!
فالنتين دي ألميدا
تجربة المطور والتقنية الأساسية – Ledger Live
- محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
- PlatoData.Network Vertical Generative Ai. تمكين نفسك. الوصول هنا.
- أفلاطونايستريم. ذكاء Web3. تضخيم المعرفة. الوصول هنا.
- أفلاطون كربون، كلينتك ، الطاقة، بيئة، شمسي، إدارة المخلفات. الوصول هنا.
- أفلاطون هيلث. التكنولوجيا الحيوية وذكاء التجارب السريرية. الوصول هنا.
- المصدر https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain
