freeCodeCamp/docs/i18n/Arabic/devops.md

عمليات المطور في freeCodeCamp.org

هذا الدليل سيساعدك على فهم مكدس البنية التحتية الخاص بنا وكيف نحافظ على المنصات الخاصة بنا. ورغم أن هذا الدليل لا يتضمن تفاصيل شاملة عن جميع العمليات، فإنه يمكن استخدامه كمرجع لفهمكم للنظم.

دعونا نعلم، إذا كان لديكم تغذية مرتدة أو استفسارات، وسيكون من دواعي سرورنا أن نوضح ذلك.

كيف يمكننا أن نبني ونختبر وننشر الكود البرمجي؟

يتم بناء هذا المستودع بشكل مستمر واختباره ونشره في مجموعات منفصلة من البنية التحتية (سيرفرات وقواعد البيانات وCDN، وما إلى ذلك).

وينطوي ذلك على ثلاث خطوات يتعين اتباعها بالتسلسل:

1. يتم دمج التغييرات الجديدة (الإصلاحات والميزات) في فرع التطوير الأساسي الخاص بنا (الرئيسية) عن طريق طلبات السحب.
2. وتجري هذه التغييرات من خلال سلسلة من الاختبارات المؤتمتة.
3. وبمجرد اجتياز الاختبارات نعلن عن التغييرات (أو تحديثها إذا اقتضى الأمر) لنشرها على بنيتنا التحتية.

بناء الشريط البرمجي - رسم خرائط فروع Git للنشر.

عادةً، سيد (فرع التطوير الافتراضي) يدمج في تجهيز الإنتاج فرع مرة واحدة في اليوم ويطلق في بنية تحتية معزولة.

هذا هو الإصدار الوسيط للمطورين والمساهمين المتطوعين. كما أنه يعرف باسم "الإنتظار" أو "بيتا".

إنه مطابق لبيئتنا الإنتاجية الحية في freeCodeCamp.org، بخلاف ذلك باستخدام مجموعة منفصلة من قواعد البيانات، الخوادم، وكلاء الويب، إلخ. تتيح لنا هذه العزلة اختبار التطوير المستمر والميزات في "الإنتاج" مثل السيناريو، دون التأثير على المستخدمين المنتظمين للمنصات الرئيسية لـ freeCodeCamp.org.

مرة واحدة فريق المطور @freeCodeCamp/dev-team سعيد بالتغييرات على منصة التجهيز ، يتم نقل هذه التغييرات كل بضعة أيام إلى فرع الإنتاج الحالي

هذا هو الإصدار النهائي الذي ينقل التغييرات إلى منصات الإنتاج لدينا على freeCodeCamp.org.

اختبار التغييرات - اختبار التكامل وقبول المستخدم.

نحن نستخدم مختلف مستويات اختبار التكامل والقبول للتحقق من جودة الشفرة. تتم جميع اختباراتنا من خلال برمجيات مثل Travis CI و Azure Pipelines.

لدينا اختبارات وحدة لاختبار حلول التحدي الخاصة بنا، واجهات برمجة تطبيقات الخادم وواجهة مستخدم العميل. هذه تساعدنا على اختبار التكامل بين المكونات المختلفة.

[!ملحوظة] نحن أيضا في عملية كتابة اختبارات المستخدم النهائي التي ستساعد في تكرار سيناريوهات العالم الحقيقي مثل تحديث البريد الإلكتروني أو إجراء مكالمة إلى خدمات API أو طرف ثالث.

وتساعد هذه الاختبارات معا في منع المشاكل من تكرار نفسها والتأكد من أننا لا ندخل خلل أثناء العمل على خلل آخر أو ميزة أخرى.

نشر التغييرات - دفع التغييرات إلى الخوادم.

لقد قمنا بتكوين برنامج التوصيل المستمر لدفع التغييرات إلى خوادم التطوير والإنتاج لدينا.

وبمجرد دفع التغييرات إلى فروع الإفراج المحمية، يبدأ تشغيل خط أنابيب البناء تلقائياً للفرع. وخطوط أنابيب البناء مسؤولة عن بناء الأعمال الفنية وإبقائها في مخزن بارد لاستخدامها في وقت لاحق.

ويمضي خط أنابيب البناء لتفعيل خط أنابيب الإفراج المقابل إذا أنجز عملية تشغيل ناجحة. وخطوط أنابيب الإصدار مسؤولة عن جمع فنون البناء، ونقلها إلى الخوادم، والسير على قيد الحياة.

حالة الإنشاءات والإصدارات متاحة هنا.

تنشيط البناء والاختبار والنشر.

وفي الوقت الراهن، لا يستطيع سوى الأعضاء في فريق المطور الدفع إلى فروع الإنتاج. التغييرات في فروع الإنتاج * يمكن أن تهبط فقط عن طريق الدمج السريع للأمام إلى أعلى.

[!ملحوظة] في الأيام القادمة سنقوم بتحسين هذا التدفق ليتم عن طريق طلبات الجذب، لتحسين إدارة الوصول والشفافية.

دفع التغييرات إلى التطبيقات المرحلية.

1. تكوين أجهزة التحكم الخاصة بك بشكل صحيح.

   git البعيد -v
   

   النتائج:

   الأصل git@github.com:raisedadead/freeCodeCamp.git (fetch)
   الأصل git@github.com:raisedadead/freeCodeCamp.git (push)
   upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
   upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
   

2. تأكد من أن فرع الرئيسي الخاص بك نقي وفي تزامن مع البث.

   git قم بالدفع الرئيسي
   git يجلب --كل --prune
   git reset --hard upstream/master
   

3. تحقق من أن ترافيس سي يقوم بتمرير فرع الرئيسي للتبسيط.

   يجب أن تكون اختبارات الدمج المستمر خضراء و باسينغ لفرع.

   التحقق من الحالة على Travis CI (لقطة الشاشة)

   
   

   إذا فشل هذا يجب عليك التوقف والتحقيق في الأخطاء.

4. تأكد من أنك قادر على بناء المستودع محلياً.

   npm تشغيل نظيف وتطوير
   

5. نقل التغييرات من الرئيسي إلى تجهيز الإنتاج عبر دمج سريع للأمام

   git الدفع بالإنتاج - مرحلة التجهيز
   git master دمج
   git push upstream
   

   [!ملاحظة] لن تكون قادراً على فرض الدفع وإذا قمت بإعادة كتابة السجل على أي حال فإن هذه الأوامر ستخطأ.

   إذا فعلوا ذلك، ربما تكون قد فعلت شيئا خاطئا وينبغي أن تبدأ من جديد.

الخطوات المذكورة أعلاه ستفعل تلقائياً تشغيل على خط أنابيب البناء لفرع الإنتاج الحالي. بمجرد أن تصبح أداة البناء جاهزة، فإنها ستؤدي إلى تشغيل على خط أنابيب الإطلاق.

يتم تشغيل خط أنابيب الإطلاق تلقائياً عند توفر أداة جديدة من خط أنابيب البناء المتصل. بالنسبة لمنصات التجهيز، هذه العملية لا تنطوي على موافقة يدوية ويتم دفع التحف إلى خوادم العميل CDN و API.

[!تلميح: تقديرات] عادة ما يستغرق تشغيل البناء 20-25 دقيقة لإكمال عملية الإصدار التي تستغرق 15-20 دقيقة للعميل، و ~5-10 دقائق لـ API لتكون متاحة على قيد الحياة. من دفع التعليمات البرمجية إلى الحياة على منصات التجهيز تستغرق العملية بأكملها ~35-45 دقيقة في المجموع.

دفع التغييرات إلى تطبيقات الإنتاج.

وهذه العملية هي في معظمها نفس منصات التجهيز، مع إجراء عدد قليل من عمليات التحقق الإضافية. هذا فقط لتأكيد، نحن لا نكسر أي شيء على FreCodeCamp.org الذي يمكنه رؤية مئات المستخدمين يستخدمونه في أي لحظة.

لا تقم بتنفيذ هذه الأوامر إلا إذا تحققت من أن كل شيء يعمل على منصة التجهيز. لا يجب عليك تجاوز أو تخطي أي اختبار عند التجهيز قبل المضي قدماً.

1. تأكد من أن فرع تجهيز الإنتاج الخاص بك هو فرع نقدي ومتزامن مع الجزء العلوي.

   git الخروج من الإنتاج وتجهيز
   git جلب --كل --prune
   git إعادة تعيين --upstream/production-packging
   

2. نقل التغييرات من الإنتاج التجهيز إلى الإنتاج الحالي عبر دمج سريع للأمام

   git دفع الانتاج-الحالي
   git دمج الانتاج - التجهيز
   git push upstream
   

   [!ملاحظة] لن تكون قادراً على فرض الدفع وإذا قمت بإعادة كتابة السجل على أي حال فإن هذه الأوامر ستخطأ.

   إذا فعلوا ذلك، ربما تكون قد فعلت شيئا خاطئا وينبغي أن تبدأ من جديد.

الخطوات المذكورة أعلاه ستفعل تلقائياً تشغيل على خط أنابيب البناء لفرع انتاج - تجهيز بمجرد اكتمال البناء، يتم حفظ التحف كملفات .zip في وحدة تخزين باردة لاسترجاعها واستخدامها لاحقاً. بمجرد أن تصبح أداة البناء جاهزة، فإنها ستؤدي إلى تشغيل على خط أنابيب الإطلاق.

[!تلميح: تقديرات] عادة ما يستغرق تشغيل البناء 20-25 دقيقة لإكماله.

خطوات إضافية لعمل الموظفين

يتم تشغيل إحدى عمليات الإصدار، سيتلقى أعضاء فريق الموظفين المطورين رسالة إلكترونية يدوية للتدخل. يمكنهم إما الموافقة على أو رفض تشغيل الإصدار.

إذا كانت التغييرات تعمل بشكل جيد وتم اختبارها على منصة التجهيز، فيمكن الموافقة عليها. ويجب منح الموافقة في غضون 4 ساعات من تاريخ إطلاق الإصدار قبل أن يتم رفضها تلقائياً. ويمكن للموظفين أن يعيدوا تحريك عملية الإفراج يدويا لطلبات الترحيل المرفوضة، أو أن ينتظروا الدورة التالية من عملية الترحيل.

لاستعمال الموظفين:

تحقق من بريدك الإلكتروني للحصول على رابط مباشر أو انتقل إلى لوحة تحكم الإصدار بعد اكتمال تشغيل البناء.

وبمجرد موافقة أحد الموظفين على الإصدار، فإن خط الأنابيب سيدفع التغييرات مباشرة إلى خوادم CDN و API الخاصة بإنتاج freeCodeCamp.org. عادة ما يستغرق ~15-20 دقيقة للعملاء، و ~5 دقائق لخوادم API لتكون متاحة على قيد الحياة.

[!تلميح: تقديرات] عملية الإصدار تستغرق عادة 15-20 دقيقة لكل نموذج من نماذج العميل، و ~5-10 دقائق لكل نموذج API لتكون متاحة للحياة. من دفع التعليمات البرمجية إلى أن تكون حية على منصات الإنتاج تستغرق العملية بأكملها ~90-120 دقيقة في المجموع (بدون حساب وقت الانتظار للحصول على موافقة الموظفين).

بناء واختبار ونشر حالة

وفيما يلي الاختبار الحالي وحالة البناء والنشر لهذا الدماغ.

نوع	فرع	الحالة	لوحة التحكم
اختبار CI	سيد		الذهاب إلى لوحة التحكم الحالة
اختبار CI	انتاج التجهيز		الذهاب إلى لوحة التحكم الحالة
بناء خط أنابيب	انتاج التجهيز		الذهاب إلى لوحة التحكم الحالة
إصدار خط أنابيب	انتاج التجهيز		الذهاب إلى لوحة التحكم الحالة
اختبار CI	الانتاج-الحالي		الذهاب إلى لوحة التحكم الحالة
بناء خط أنابيب	الانتاج-الحالي		الذهاب إلى لوحة التحكم الحالة
إصدار خط أنابيب	الانتاج-الحالي		الذهاب إلى لوحة التحكم الحالة

الوصول المبكر واختبار بيتا

نحن نرحب بك لاختبار هذه الإصدارات في وضع "اختبار تجريبي عام" والحصول على الوصول المبكر إلى الميزات القادمة إلى المنصات. أحياناً يشار إلى هذه الميزات/التغييرات باسم التالي، بيتا، الإنتخاب، إلخ.

إسهاماتك عن طريق الإفادة المرتدة وتقارير الإصدار سوف تساعدنا في إنشاء منصات الإنتاج في freeCodeCamp. rg أكثر مرونةو ثابت و مستقر للجميع.

نشكرك على الإبلاغ عن الأخطاء التي تواجهك ومساعدتك في جعل CodeCamp.org أفضل. أنت صخر!

تحديد النسخة القادمة من المنصات

يتوفر حاليا إصدار اختبار تجريبي عام في:

freecodecamp.dev

NoTE] اسم النطاق مختلف عن freeCodeCamp.org. وهذا متعمد لمنع فهرسة محرك البحث وتجنب اللبس للمستخدمين المنتظمين للمنصة.

تحديد النسخة الحالية من المنصات

النسخة الحالية من المنصة متوفرة دائما في freeCodeCamp.org.

يدمج فريق إدارة الإنتاج التغييرات من فرع التجهيز الإنتاجي إلى التيار الإنتاجي عند تحرير التغييرات. يجب أن يكون الالتزام الأعلى ما ترونه مباشرة على الموقع.

يمكنك تحديد النسخة الدقيقة المنشورة عن طريق زيارة سجلات البناء والنشر المتاحة في قسم الحالة. بدلاً من ذلك، يمكنك أيضاً ربطنا في غرفة الدردشة المساهمين لتأكيدها.

القيود المعروفة

هناك بعض القيود المعروفة والمقايضات عند استخدام الإصدار التجريبي من المنصة.

• جميع البيانات / التقدم الشخصي على هذه المنصات التجريبية لن يتم حفظها أو نقلها إلى الإنتاج.

  المستخدمين على إصدار بيتا سيكون لديهم حساب منفصل عن الإنتاج. النسخة التجريبية تستخدم قاعدة بيانات منفصلة ماديا عن الإنتاج. وهذا يعطينا القدرة على منع أي خسارة عرضية للبيانات أو التعديلات. قد يقوم فريق ديف بتطهير قاعدة البيانات على نسخة بيتا هذه حسب الحاجة.

• لا توجد ضمانات بشأن الوقت الإضافي للمنصات التجريبية وموثوقيتها.

  ومن المتوقع أن يكون الانتشار متكررا ومتكررا بسرعة، وأحيانا عدة مرات في اليوم. ونتيجة لذلك، سيكون هناك توقف غير متوقع في بعض الأحيان أو وظائف معطلة على النسخة التجريبية.

• لا ترسل المستخدمين المنتظمين إلى هذا الموقع كتدبير لتأكيد إصلاح

  وموقع بيتا كان ولا يزال دائما يتمثل في زيادة التنمية والاختبار المحليين، لا شيء آخر. إنه ليس بوعد بما هو قادم، ولكن لمحة عما يجري العمل عليه.

• قد تبدو صفحة تسجيل الدخول مختلفة عن الإنتاج

  نحن نستخدم مستأجر اختبار لـ freecodecamp.dev على Auth0، وبالتالي ليس لدينا القدرة على تعيين نطاق مخصص. هذا يجعل من الممكن أن تظهر جميع إعادة توجيه المكالمات وصفحة تسجيل الدخول في نطاق افتراضي مثل: https://freecodecamp-dev.auth0.com/. وهذا لا يؤثر على هذه الوظيفة التي تقترب من الإنتاج بقدر ما يمكننا الحصول عليه.

المسائل المتعلقة بالإبلاغ وترك التعليقات

الرجاء فتح مشكلات جديدة للمناقشات والإبلاغ عن الأخطاء. يمكنك تسميتهم كـ الإصدار: التالي/التجريبي للتجربة.

يمكنك إرسال بريد إلكتروني إلى dev[at]freecodecamp.org إذا كان لديك أي استفسار. كما هو الحال دائمًا يجب إبلاغ جميع نقاط الضعف الأمنية إلى الأمن[at]freecodecamp.org بدلاً من تعقب الجمهور والمنتدى العام.