هذه المقالة هي امتداد لعدد من المقالات المنشورة هنا في وقت سابق والمخصصة للمراحل:
- بيان المتطلبات
- تصميم
- التطبيقات. طبقة الخدمة
يصف كيف قمنا بتنظيم عملية التطوير من خلال إشراك مطورين من مجتمع Magento منذ بدء المشروع في منتصف الصيف الماضي والذي توصلنا إليه مع إصدار
General Availability الذي تم
إصداره الأسبوع الماضي.
عملية التنمية
تم تنفيذ جميع الأعمال في المشروع مع مبرمجين من مجتمع Magento ، الذين انضموا إلى التطوير على أساس تطوعي ،
وتولى المهام من الأعمال المتراكمة للمشروع التي كانت مثيرة للاهتمام بالنسبة لهم ، وعندما أكملوهم ، وضعوا طلبات السحب على GitHub.
ونتيجة لذلك ، كان هناك أكثر من 80 من هؤلاء الأشخاص الذين قاموا بإنشاء تجمع طلب واحد على الأقل ، وفي المجموع قاموا بوضع أكثر من 800 تجمع طلبات.
تم إجراء التطوير وجهاً لوجه في أحداث hackathon ، والتي تسمى عادة "يوم المساهمة" في عالم Magento ، وتم توزيعها عندما عمل الرجال على المشروع عن بُعد في وقت مناسب قادمًا لفتح العروض التوضيحية على المشروع لإظهار النتائج وطرح الأسئلة.
أحداث تنسيق "يوم المساهمة" ، حيث يمكن للمبرمجين القدوم والدخول إلى المشروع بسهولة شديدة ، بالإضافة إلى مناقشة المشكلة مع مهندسي النظام والاطلاع على الإجراء ، أصبحت مراجعة التعليمات البرمجية شائعة للغاية ، حيث يتعلم المبرمجون المجتمعون بسرعة ويحصلون على التوصيات والنصائح. من المهندسين الأساسيين الذين يعملون مع النظام ، وكذلك اكتساب المهارات حول كيفية حل المشاكل النموذجية باستخدام الآليات التي يوفرها الإطار ؛ في الوقت نفسه إجراء تحسينات مفيدة للنظام نفسه. كما أوضحت ممارسة الفوز في مثل هذا النموذج ، فإنه ينطبق على جميع المشاركين في العملية ، بما في ذلك الوكالات التي تستخدم المبرمجين الذين يشاركون في المشروع كمساهمين ، لأن هذه الوكالات يمكنها استخدام المعرفة التي اكتسبها موظفوها كميزة تنافسية في مشاريعهم المستقبلية.
على سبيل المثال ، قبل أسبوعين من الإصدار الرسمي ، أطلقت Strix ، التي شاركت بنشاط في Code Contribution لمشروع MSI ، بالفعل مشروعها على أساس Magento 2.3 + MSI Beta ، والذي تمت مشاركته على
مدونتها .
وإذا كان هناك 15 حدثًا من هذا القبيل في عام 2017 ، فكان هناك أكثر من 40 حدثًا في عام 2018.
جمعت العديد من الأحداث أكثر من 100 مساهم في مكان واحد ، مثل يوم المساهمة الأخير في كييف قبل مؤتمر MageConf18 أو Magento Live EU Contribution Day في برشلونة:
للتواصل السريع مع المطورين ، قمنا بتخصيص قناة سلاك منفصلة للاتصال ، والتي تتكون الآن من أكثر من 350 مطورًا.
قام Slack باستبدال أي برامج مراسلة فورية ، كما قدم أدوات لتلقي التعليقات بسرعة من المجتمع مع المنتجات والحلول التقنية التي كنا بصدد تنفيذها. لقد فعلنا ذلك بمساعدة الأدوات القياسية للاستبيانات في الركود.
لفترة طويلة ، كان المصدر الرئيسي للتوثيق للمشروع هو
ويكي المشروع ، والذي يشمل جميع التصميمات الفنية ووثائق المستخدم ومحفوظات الاتصالات في سلاك ، ووصف للقرارات التي اتخذت في مسابقات التهيأ والوقوف.
كل يوم جمعة ، يعرض المساهمون الذين قدموا مجموعة من طلبات المشروع ، وكذلك أولئك الذين لديهم أسئلة / اقتراحات حول كيفية تحسين شيء ما ، نتائجهم في اجتماع تجريبي مفتوح ، يمكن لأي شخص الاتصال به عبر Zoom:
ويمكن لجميع أولئك الذين لم يكن لديهم وقت للتجمع مشاهدة التسجيل ، حيث يتم تسجيل كل تجمع من هذا القبيل ووضعه على
YouTube . على سبيل المثال ، هذا هو سجل لآخر عرض توضيحي حيث يوضح المساهم في Riccardo Tempesta خوارزمية اختيار المصدر للاختيار الأمثل للمستودعات للتسليم استنادًا إلى المسافات بين عنوان التسليم وعناوين المستودعات مع البضائع
إن أصعب شيء في مثل هذا النموذج لتطوير البرمجيات ، والذي لا يوجد فيه أشخاص متفرغون باستمرار في المشروع ، هو التخطيط لوقت توافر التجهيزات وتحديد
سرعة وسرعة Scrum للمقاييس الرئيسية لتقييم متى يمكن تقديم ملائمة معينة. في الواقع ، لا يجوز للمساهم ، الذي استثمر 20-30 ساعة في المشروع خلال أسبوع واحد ، أن يقضي حتى ساعة واحدة في الأسبوع المقبل ، لأنه في وظيفته الرئيسية سيكون هناك انسداد ، ستبدأ الزوجة / الفتاة بالغيرة أو بالنظر إلى أي ظروف أخرى ، لأن الشخص قد يكون توقف عاديا كونها مثيرة للاهتمام. مطورو الطرف الثالث لا ، ولا يمكن أن يكون لديهم أي التزامات تجاه المشروع. يشاركون من أجل المتعة والمعرفة الجديدة. وهذا يجب أن نعطيهم دون المطالبة بأي شيء في المقابل!
حرق الرسم البياني لتطبيق Milestone 2 بنيت مع ZenHub .في نظرية إدارة المشروع ، يحاولون عادة إصلاح أحد المؤشرين نطاق ثابت أو ثابت وقت التسليم ، في ظل حالة "الموارد الثابتة".
في حالة النموذج ، عندما يشارك المطورين من المجتمع فقط ، ليس لدينا موارد ثابتة وكانت أي محاولات لإصلاح وقت التسليم صعبة للغاية.
لذلك ، في النهاية ، قررنا اختيار ومتابعة عملية
التطوير التي تعتمد على الميزة (FDD) . تحديد وقت رسمي كافي للتكرار (علامة فارقة) لمدة 2-3 أشهر. ويشكل تكوين الأعمال المتراكمة لهذا الحدث الهام ، وجذب المجتمع مرة أخرى للمساعدة في تحديد أولويات المهام في هذه الأعمال المتراكمة ، ميزة أخرى من سمات نموذج التطوير هذا ، حيث أننا لا ننشئ ونحدد أولويات تراكم المنتج. غالبًا ما يحدد المساهمون ، خاصةً إذا كانوا يمثلون الشركات ، أولوياتهم الخاصة لبعض المهام ، والتي تمليها مشاريعهم الحالية أو المستقبلية. يهتم هؤلاء المساهمون بتسليم مستودع المشروع بشكل أساسي ما هو مثير لهم. كجزء من الحدث الرئيسي ، نعمل بالتوازي على القصص ، ويمكننا إصدارها بمجرد أن نكون مستعدين ، أو بمجرد أن يصل وقت نهاية التكرار. إذا لم تكتمل بعض القصص كجزء من التكرار ، فإنها تنتقل إلى المعلم التالي.
والأهم من ذلك - لقد تخلصنا من تاريخ إصدار المنتج الرئيسي - Magento 2 والآن يمكننا إصداره بشكل مستقل عنه! لماذا
نفرد حزمة الملحن meta ، والتي تشير إلى جميع وحدات الجرد والرابط إلى metapackage نفسه من المستودع الرئيسي (بشكل أكثر دقة ، من metapackage للمستودع الرئيسي) يبدو كما يلي:
"magento/inventory-composer-metapackage": "^1.0.3"
أي
يتم استخدام
الحرف ^ للإشارة إلى إصدار الحزمة.
وبالمثل ، يشار إلى روابط لجميع إصدارات وحدات المشروع داخل الحزمة مع إضافة رمز ^:
{ "name": "magento/inventory-composer-metapackage", "version": "1.0.3", "description": "Metapackage with Magento Inventory modules for simple installation", "type": "metapackage", "require": { "magento/inventory-composer-installer": "^1.0.3", "magento/module-inventory": "^1.0.3", "magento/module-inventory-admin-ui": "^1.0.3", "magento/module-inventory-api": "^1.0.3", "magento/module-inventory-bundle-product": "^1.0.3", "magento/module-inventory-bundle-product-admin-ui": "^1.0.3", "magento/module-inventory-cache": "^1.0.3", "magento/module-inventory-configurable-product": "^1.0.3", "magento/module-inventory-catalog-api": "^1.0.3", "magento/module-inventory-catalog": "^1.0.3", "magento/module-inventory-catalog-admin-ui": "^1.0.3", "magento/module-inventory-catalog-search": "^1.0.3", "magento/module-inventory-configurable-product-admin-ui": "^1.0.3", "magento/module-inventory-configurable-product-indexer": "^1.0.3", "magento/module-inventory-configuration": "^1.0.3", "magento/module-inventory-configuration-api": "^1.0.3", "magento/module-inventory-grouped-product": "^1.0.3", "magento/module-inventory-grouped-product-admin-ui": "^1.0.3", "magento/module-inventory-grouped-product-indexer": "^1.0.3", "magento/module-inventory-import-export": "^1.0.3", "magento/module-inventory-indexer": "^1.0.3", "magento/module-inventory-multi-dimensional-indexer-api": "^1.0.3", "magento/module-inventory-low-quantity-notification": "^1.0.3", "magento/module-inventory-low-quantity-notification-api": "^1.0.3", "magento/module-inventory-low-quantity-notification-admin-ui": "^1.0.3", "magento/module-inventory-product-alert": "^1.0.3", "magento/module-inventory-reservations": "^1.0.3", "magento/module-inventory-reservations-api": "^1.0.3", "magento/module-inventory-sales": "^1.0.3", "magento/module-inventory-sales-admin-ui": "^1.0.3", "magento/module-inventory-sales-api": "^1.0.3", "magento/module-inventory-sales-frontend-ui": "^1.0.3", "magento/module-inventory-shipping": "^1.0.3", "magento/module-inventory-shipping-admin-ui": "^1.0.3", "magento/module-inventory-source-deduction-api": "^1.0.3", "magento/module-inventory-source-selection-api": "^1.0.3", "magento/module-inventory-source-selection": "^1.0.3" } }
المشغل ^ موجود لتحقيق أقصى توافق أثناء كتابة التعليمات البرمجية ، حتى نتمكن من القيام بإصدارات MSI داخلية حتى نجري تغييرات
غير متوافقة مع الإصدارات السابقة للمشروع "
> = 1.0.3 <2.0.0 ".
من ناحية ، يوفر هذا مرونة كافية لمشروعات مثل MSI ، والتي تسمى عادةً Magento Core Bundle Extensions (CBE). تقع هذه المشاريع في مستودعات GitHub منفصلة ، ولها تسلسل زمني خاص بها من الإصدارات ، وهي معزولة قدر الإمكان عن غيرها من المشاريع المماثلة وعن المنتج الرئيسي Magento 2. من حيث العزلة ، من الناحية الإجرائية ، هو مثل اتباع
قانون كونواي . وعلى الصعيد العالمي ، يتوافق هذا النهج التنموي الخاص بالخدمات والمشاريع الجديدة في Magento 2 مع مفهوم "
عزل الخدمة" المقدم من مجلس Magento المعماري. ولكن مع قدر أكبر من المرونة تأتي مسؤولية أكبر (
مع وجود قوة كبيرة تتحمل مسؤولية كبيرة ) ، لأنه في هذه الحالة ، يجب أن تتبع هذه المشروعات بصرامة الإصدار الدلالي (
SemVer ) لمنع التغييرات غير المتوافقة مع الإصدارات السابقة ولضمان سهولة ترقيات المستخدمين.
تتوفر الأعمال المتراكمة للمشروع نفسه ، بالإضافة إلى جميع التكرارات (بما في ذلك التكرارات المكتملة) على صفحة
MSI Roadmap .
على سبيل المثال ، هذا هو المعلم المتراكم 3 ، الذي بدأنا للتو العمل:
وفي الختام ، أود مرة أخرى أن أشكر
جميع المساهمين الذين انضموا إلى المشروع وساعدوا في الوصول إلى مرحلة إصدار الجمعية العامة. لن ننجح بدونك!
