تدير جامعة ستانفورد مثيلًا لقاعدة كود OpenEdX التي يطورها فريق من المهندسين بنشاط. نحافظ على الشوكة الخاصة بنا في github.com/Stanford-Online/edx-platform ونحاول إبقاء الشوكة الخاصة بنا قريبة من edX master من خلال الدمج شهريًا من مستودع منصة edx الرئيسي لـ edx (github.com/edx/edx-platform). نحن نفضل كود الأرض من خلال طلبات السحب (PRs) إلى مستودع edX الرئيسي ، لكن في بعض الأحيان لا يكون ذلك ممكنًا ، حيث نقوم بشكل دوري ببناء ميزات مخصصة خاصة بجامعة ستانفورد. من خلال التكرار ، اعتمدنا عملية إصدار محددة بوضوح تستوعب مهام سير العمل لكل من الدمج من مستودع edX الرئيسي والاحتفاظ بأنشطتنا منفصلة رئيسي فرع. نظرًا لأننا ندير موقعًا على شبكة الإنترنت به عدد كبير من المستخدمين ، فإننا نعتقد أن استقرار الإصدارات أمر بالغ الأهمية. هذا يعني أننا نحاول جاهدين إبعاد الشفرة السيئة عن ملف الافراج عن الفرع ، وعملية التحرير تسهل ذلك.
نظرًا لأننا نقدم تقارير العلاقات العامة إلى edX وكذلك لأنفسنا ، فنحن بحاجة إلى الوصول إلى مستودعات edX من بيئات التطوير لدينا ، لذلك يقوم معظم المطورين في ستانفورد بتشغيل بيئات git مع جهازي تحكم عن بعد على الأقل (أو أحيانًا أكثر مع أجهزة التحكم عن بعد الشخصية وتلك الخاصة بـ زملاء العمل): الأصل، مستودع كود ستانفورد ؛ و ضد التيار، مستودع كود edX ، والذي يمكننا من خلاله التحقق من الفرع الرئيسي لعمل PRs لـ edX. نحن نستخدم هذا أيضًا ضد التيار remote لدمج تغييرات التعليمات البرمجية من edX أثناء عملية الإصدار لدينا.
هذا هو المكان الذي رأيت فيه الحاجة إلى رسم تخطيطي يشرح عملية الإصدار. أنا شخص بصري ، ورسم شيء ما هو كيف أفهم الأشياء. هذا هو الرسم التخطيطي الخاص بي للمساعدة في وصف سير عمل التطوير والإصدار:
إنه مفيد بشكل خاص لأن مطورينا يتناوبون على تحمل المسؤولية عن الإصدارات في نظام "Release Master". يحافظ الرسم التخطيطي على تناسق دورة الإصدار الخاصة بنا بين الإصدارات ويقلل من الأخطاء.
فيما يلي خطة إصدار باستخدام الرسم التخطيطي كدليل:
1. أولاً نقوم بإنشاء ملف rc فرع من فرعنا الرئيسي ، مع أخذ أي تطوير تم دمجه فيه رئيسي منذ الإصدار الأخير.
1 أ. إذا أردنا دمج ضد التيار الافراج عن فرع في rc فرع ، نفعل ذلك هنا.
في هذه المرحلة ، لدينا مرشح إصدار يمكننا اختباره ، وبمجرد أن نتأكد من أنه لن يكسر أي شيء ، قم بتثبيته على آلات الإنتاج الخاصة بنا.
2. الآن نقوم بدمج الفرع rc في فرع الافراج عن (يجب أن يكون هذا أمرًا بسيطًا للتقديم السريع ؛ إذا لم يكن كذلك ، فإن الإصدار السابق به مشكلة!).
3. الآن الافراج عن فرع (والمدمج ضد التيار code) في ملف رئيسي فرع للحفاظ على تزامن الفرعين مع بعضهما البعض.
لاحظ أنه تم إنشاء فروع مميزة من رئيسي ودمجت مرة أخرى ليتم إصدارها في دورة الإصدار العادية. من ناحية أخرى ، فإن الإصلاحات العاجلة متفرعة من الافراج عن، تم دمجه مرة أخرى في الافراج عن، ودُفعت على الفور إلى الإنتاج ، ثم اندمجت مرة أخرى رئيسي للحفاظ على التزامن. لاحظ أيضًا ذلك الافراج عن التغييرات و ضد التيار عمليات الدمج لا تجعلها في رئيسي ما لم تعتبر آمنة بعد الاختبار ، والتي تعزل رئيسي من الحشرات كذلك.
وهذا كل شيء! نستخدم نموذج التفريع هذا لكل مستودع متشعب نحتفظ به ، والذي يحافظ على كل شيء متسقًا ويمكن التنبؤ به.
