التطوير بالمحور مقابل GitFlow للتسليم الأسبوعي

لماذا يصبح الإصدار الأسبوعي فوضويًا مع نموذج فروع غير مناسب

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

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

عندما يعمل سير العمل ضدك، فعادةً ما يشعر الفريق بهذا الشكل:

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

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

لهذا السبب تقارن الفرق بين التطوير بالمحور وGitFlow عندما تنتقل إلى إيقاع إصدار أسبوعي. السؤال المفيد ليس أيهما شائع، بل أيهما يقلل ألم الدمج، ويحافظ على توقعية الإصدار، ويجعل التصحيحات العاجلة آمنة وسريعة، ويحافظ على معنى اختبارات QA.

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

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

التطوير بالمحور وGitFlow بلغة بسيطة

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

• التطوير بالمحور يبقي معظم العمل قريبًا من main.
• GitFlow يحتفظ بممرات منفصلة للعمل الجاري واستقرار الإصدار.

التطوير بالمحور (بمصطلحات بسيطة)

يعامل التطوير بالمحور main (المحور) كمركز. يعمل الناس في فروع قصيرة العمر (ساعات إلى يوم أو يومين)، يدمجون بشكل متكرر، ويحافظون على main في حالة قابلة للإصدار.

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

GitFlow (بمصطلحات بسيطة)

عادةً ما يستخدم GitFlow فرع develop طويل العمر حيث تهبط الميزات أولًا، بالإضافة إلى فروع feature منشأة من develop. قرب وقت الإصدار، تقطع فرع release/* لتثبيت الاختبارات. إذا تعطل الإنتاج، تقطع فرع hotfix/* (غالبًا من main) وتدمجه مرة أخرى.

هذا النموذج يُحسن للفصل: يمكن للعمل الجاري أن يستمر على develop بينما يتم اختبار وتصحيح فرع الإصدار.

الكثير من الألم يأتي من سوء الفهم الشائع:

• اعتبار التطوير بالمحور على أنه "لا فروع" (هو لا يزال يستخدم فروعًا، لكنها قصيرة العمر).
• استخدام GitFlow دون إنشاء فرع إصدار حقيقي، فيصبح develop منطقة تجهيز غير مستقرة.
• ترك فروع الميزات لأسابيع، مما يحول أي نموذج إلى مشكلة دمج.
• الخلط بين "قابل للنشر" و"كل شيء مُنجز" بدلاً من "آمن للنشر".

احتكاك الدمج: ما الذي يسببه فعليًا

تأتي تعارضات الدمج عادةً من مصدرين: فروع تعيش لفترة طويلة جدًا، والعديد من الأشخاص يغيرون نفس المناطق دون تنسيق.

الفرق العملي الأكبر بين التطوير بالمحور وGitFlow هو مدة بقاء العمل منفصلًا قبل أن يلتقي عمل الآخرين.

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

مع GitFlow، قد يجلس العمل في فروع الميزات أطول دون التأثير على مطورين آخرين يوميًا. التكلفة تظهر لاحقًا كحدث دمج أكبر: feature إلى develop، develop إلى release/*، وrelease/* إلى main. كل دمج هو اجتماع أكبر للتغييرات، لذا تكون التعارضات أكثر احتمالًا وأصعب للفك. للإصدار الأسبوعي، تميل تلك الدمجات الكبيرة إلى الحدوث تمامًا عندما يريد الفريق الاختبار.

يتغير حمل مراجعة الكود أيضًا. التطوير بالمحور عادةً يعني مراجعات أكثر، لكن كل مراجعة أسرع للفهم. GitFlow غالبًا يعني مراجعات أقل لكنها أثقل، بالإضافة إلى وقت مراجعة إضافي أثناء دمجات الإصدار عندما يكون الجميع متعبًا.

لتقليل احتكاك الدمج في أي نموذج:

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

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

توقعية الإصدار لإيقاع أسبوعي

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

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

بوابات الجودة غالبًا ما تكون أبسط لأن هناك مكانًا واحدًا للتحقق:

• يجب أن تجتاز الاختبارات الآلية على main.
• يختبر QA مرشحًا ثابتًا، لا ما هبط قبل ساعة.
• تُكتب خطوات النشر والرجوع للخلف.
• هناك وقت قطع واضح للإصدار (حتى لو استمرت الالتزامات بالهبوط).

في GitFlow، تأتي التوقعية من فرع الإصدار الذي يعمل كمنطقة تجميد. تختار حدًا، تنشئ release/*، ولا تسمح إلا بالتغييرات اللازمة للشحن. هذا الحد يساعد، لكنه يضيف تنسيقًا لأن الإصلاحات عادةً ما تحتاج تطبيقها في أكثر من مكان (release وdevelop).

يُتعامل مع العمل غير المكتمل بشكل مختلف:

• التطوير بالمحور: دمج الأجزاء الآمنة وإبقاء الباقي خلف الأعلام.
• GitFlow: إبقاء العمل غير المكتمل في develop واستبعاده من فرع الإصدار.

مثال: إذا كانت تحسينات صفحة الدفع نصف مكتملة يوم الأربعاء، يمكن للتطوير بالمحور دمج التحسينات الآمنة وإبقاء واجهة المستخدم الجديدة مخفية. GitFlow عادةً يحتفظ بها في develop، يشحن بدونها، ويكملها للإصدار الأسبوعي التالي.

مسار التصحيح العاجل: أسرع طريق آمن إلى الإنتاج

الـ hotfix ليس عملًا عاديًا. يحتاج سرعة، مخاطرة منخفضة، ومسارًا يعيد التغيير إلى مكان عمل الفريق حتى لا تصلح نفس الخطأ مرتين.

ابدأ بسؤال واحد: ما الكود الدقيق الجاري في الإنتاج الآن؟ إذا لم تستطع الإجابة عن ذلك خلال ثوانٍ، تتحول التصحيحات العاجلة إلى تخمين.

التصحيحات العاجلة في التطوير بالمحور

قد تبدو تصحيحات التطوير بالمحور أبسط لأن main يعامل كمصدر الحقيقة.

سير شائع:

• اقطع فرعًا قصير العمر من التزام الإنتاج (غالبًا من main).
• قم بأصغر إصلاح ممكن (أضف اختبارًا إن أمكن).
• ادمج سريعًا مرة أخرى إلى main.
• انشر من main وعلّم الإصدار.

لأن الفريق يندمج في main كثيرًا، يصبح الـ hotfix جزءًا طبيعيًا من الإصدار الأسبوعي التالي. الخطر الرئيسي هو كسر قاعدة "main قابل للإصدار" بترك عمل نصف منجز في main. تساعد feature flags، لكن اجعلها مغلقة افتراضيًا وتحقق من الـ hotfix دون تفعيل ميزات غير ذات صلة.

التصحيحات العاجلة في GitFlow

في GitFlow، عادةً ما تبدأ التصحيحات من main (الإنتاج)، ثم يجب دمجها مرة أخرى في develop حتى لا يُفقد الإصلاح.

سير آمن:

• فرع hotfix/* من main عند وسم الإنتاج.
• أصلح وأصدر (إما من فرع الـ hotfix أو بعد الدمج إلى main).
• ادمج الـ hotfix إلى main وأيضًا إلى develop.
• إذا كان فرع release/* موجودًا، ادمجه هناك أيضًا.

الفشل الأكثر شيوعًا هو نسيان أحد هذه الدمجات. بعد أسبوع، "يعود" الخطأ لأن develop لم يحصل على التصحيح.

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

كيف نحافظ على استقرار بيئات QA (دون عرقلة الفريق)

يفشل الإصدار الأسبوعي عندما يعني "QA" "ما تم نشره الآن فقط." سَمِّ بيئاتك وأعطِ كل واحدة وظيفة: dev للملاحظات السريعة، QA لاختبارات الفريق، staging لفحوص الإصدار، prod للعملاء. إذا لم تستطع شرح غرض البيئة في جملة واحدة، سيستخدمها الناس بشكل خاطئ.

قواعد تمنع الأهداف المتحركة

الـ QA المستقر أقل ارتباطًا بنموذج الفروع وأكثر بما تنشره فعليًا.

في العمل بالمحور، لا تنشر التزامات عشوائية إلى QA. انشر مرشحًا مثبتًا (بناء مؤشَّم، رقم بناء، أو فرع مرشح قصير العمر) يجتاز نفس الفحوص في كل مرة. يحصل QA على شيء ثابت للاختبار بينما يستمر التطوير على main.

في GitFlow، عادةً ما يتتبع QA فرع الإصدار. الفخ هو ترك فرع الإصدار يواصل التغيير بعد بدء QA. بمجرد أن يبدأ QA، عامل فرع الإصدار كعقد: اقبل إصلاحات معتمدة فقط، ومن خلال عملية واضحة.

مجموعة قواعد صغيرة تجعل أي نهج متوقعًا:

• انشر إلى QA فقط من البنايات الناجحة.
• ثبّت النسخة المنشورة (وسم، رقم بناء، أو رأس فرع مرشح) وأعلنها.
• قصر تغييرات QA على إصلاحات الأخطاء، لا ميزات جديدة.
• أعد ضبط بيانات الاختبار بجدول موثق وما يُمحى.
• احتفظ بالتكوين ككود لتقليل انجراف البيئة.

إذا كان فريقك يستخدم AppMaster لجزء من البناء، حافظ على المبدأ نفسه: جدِّد وانشر بناء معين لـ QA، لا مجموعة تعديلات دائمة التغير.

عندما تشارك عدة فرق QA

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

مثال: الفريق A يصدق على مرشح الإصدار الأسبوعي، لذا يبقى QA مثبتًا على البناء 1842 حتى الموافقة. يمكن للفريق B الاستمرار في دمج الإصلاحات، لكن تلك التغييرات تنتظر المرشح التالي بدلًا من تغيير ما يختبره QA منتصف الدورة.

خطوة بخطوة: اختر سير عمل يمكن لفريقك اتباعه كل أسبوع

اكتب ما يعنيه "الإصدار الأسبوعي" بالنسبة لكم. اختر يومًا ووقتًا للإصدار، قرر مستوى المخاطرة المقبول (مثل "لا أخطاء P1 معروفة"), وسجل حجم الفريق ومناطق التوقيت. هذا يمنع نقاشات الفروع من أن تتحول إلى جدالات حول الأولويات.

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

سير أسبوعي بسيط يمكنك تكييفه:

• اجعل عمر الفروع قصيرًا (ساعات إلى يوم أو يومين) وادمج على الأقل يوميًا.
• أضِف حواجز أمان: CI سريع، مراجعة قصيرة مطلوبة، ومجموعة صغيرة من الاختبارات الآلية التي تكتشف الأعطال الحقيقية.
• قرر كيف تتحكم في النطاق: feature flags، فرع إصدار قصير قبل نهاية الأسبوع، أو وسم للالتزام الدقيق للإصدار.
• عرّف خطوات التصحيح العاجل: من يمكنه إطلاقها، ما الفحوص المطلوبة، وكيف يعود الإصلاح إلى الخط الرئيسي.
• حافظ على استقرار QA: قرر ماذا يتتبع QA (فرع إصدار أم مرشح مثبت) ولا تغيّره أثناء الاختبار إلا إذا أعدت دورة الاختبار.

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

مثال: إصدار أسبوعي واقعي في كلا النموذجين

تخيَّل فريق منتج مكوّن من 6 أشخاص يشحنون كل جمعة. يقوم مختبران من QA بمشاركة بيئة staging واحدة، لذا إذا كانت غير مستقرة، يتوقف الاختبار للجميع.

أسبوع مزدحم مع GitFlow

الإثنين: ثلاثة مطورين يكملون ميزات ويفتحون PRs إلى develop. يبدأ QA اختبار staging المبني من develop.

الأربعاء: الفريق يقطع release/1.8 لحماية شحنة الجمعة. يواصل العمل الجديد الهبوط في develop، لكن يركز QA الآن على بناء الإصدار.

الخميس بعد الظهر: يظهر خطأ متأخر. يصلح في release/1.8 أولًا حتى يعيد QA الاختبار بسرعة. ثم يدمج شخص ذلك الإصلاح مرة أخرى في develop، وهنا يحدث الخطأ غالبًا.

إيقاع نموذجي:

• اثنَان-ثلاثاء: تندمج الميزات في develop، ويتغير staging كثيرًا.
• الأربعاء: إنشاء release/1.8، ويتحول staging إلى بنى الإصدار.
• الخميس: إصلاح في release/1.8، ثم الدمج إلى develop.
• الجمعة: دمج release/1.8 إلى main، علم ونشر.

نفس الأسبوع مع التطوير بالمحور

يتشكل الأسبوع حول اندماجات صغيرة ومتكررة إلى main. تُشحن الميزات خلف الأعلام حتى يمكن دمج العمل غير المكتمل دون التأثير على المستخدمين.

الاثنين إلى الخميس: يدمج المطورون تغييرات صغيرة يوميًا. يختبر QA مرشحًا مثبتًا.

الثلاثاء: يظهر مشكلة في الإنتاج. التصحيح هو فرع قصير من main، يُدمج فورًا بعد المراجعة، ثم يُرفع إلى الإنتاج. لأن main هو مصدر الحقيقة، لا يوجد خطوة دمج إضافية للعودة.

مهما كان النموذج، يحتاج الفريق إلى قواعد ترقية واضحة:

• يعمل staging على أحدث مرشح مثبت، لا على كل التزام جديد.
• يطلب QA مرشحًا جديدًا عندما يكون جاهزًا، لا تلقائيًا.
• لا يمكن تغيير المرشح إلا لإصلاحات لجمعة الإصدار.
• كل شيء آخر ينتظر خلف الأعلام أو يبقى خارج المرشح.

الأخطاء الشائعة التي تخلق تراخيًا وQA غير مستقر

معظم الفرق لا تفشل لأنها اختارت النموذج "الخاطئ". تفشل لأن العادات اليومية لا تطابق النموذج، لذا يصبح QA ضجيجيًا وتشعر الإصدارات بالعشوائية.

مشكلة شائعة هي ترك الفروع لعدة أيام لأن "ليست جاهزة." ينحرف الكود عن main، تتراكم التعارضات، وينتهي الأمر بـ QA لاختبار خليط من الأعمال القديمة والجديدة التي لا يستطيع أحد تكرارها.

خطأ آخر هو استخدام GitFlow بدون تجميد حقيقي. من المفترض أن يثبت فرع الإصدار، لكن الفرق تستمر في إدخال "مجرد تغيير واحد آخر". هذا يحول فرع الإصدار إلى خط رئيسي ثانٍ، ولا أحد يعرف ما يوافق عليه QA.

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

الأخطاء التي تخلق أكبر قدر من التراخي:

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

احتفظ بمجموعة قواعد يكررها الجميع:

• يختبر QA مرشحًا مثبتًا فقط.
• تروِّج نفس الأرتيفاكت من QA إلى الإنتاج.
• لكل بيئة مالك وجدولة لإعادة الضبط.
• تعود التصحيحات العاجلة إلى الخط الرئيسي في نفس اليوم.

قائمة تحقق سريعة للإصدار الأسبوعي بدون مفاجآت

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

• هل هناك فرع واحد يمكنك نشره بأمان اليوم؟ ينبغي أن يبني، يجتاز اختبارات الدخان، ويتجنب التغييرات نصف الموصولة.
• هل تبقى طلبات السحب صغيرة وتُرسل خلال يوم أو يومين؟ PRs طويلة العمر عادةً تعني ملاحظات قديمة وتعقيدات أكبر.
• هل يختبر QA بناء ثابت، لا هدفًا متحركًا؟ يجب أن يصدق QA رقم بناء محددًا أو مرشح إصدار.
• هل يمكنك إبقاء العمل غير المكتمل خارج الإصدار دون دراما؟ feature flags أو تبديلات التكوين أو قاعدة قطع نطاق واضحة.
• هل يستطيع شخص تنفيذ hotfix والرجوع للخلف دون تخمين؟ دليل تشغيل قصير يغلب المعرفة القبلية.

إن أردت هدفًا قابلًا للقياس: ثبّت QA على مرشح إصدار وابقِ ذلك المرشح دون تغيير إلا للإصلاحات المقصودة.

الخطوات التالية: اختر تغييرًا واحدًا لتجربته الأسبوع القادم

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

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

إذا كان عدم استقرار QA هو الألم الأكبر، ابدأ بتثبيت ما يختبره QA وتحديد خطوة ترقية بسيطة.

تجربة تجريبية خفيفة:

• اختر مستودعًا واحدًا وفريقًا واحدًا.
• ضع حدًا لعمر الفرع (مثلاً: لا فرع أقدم من يومين).
• ثبّت QA على بناء واحد ولا تغيّره إلا عبر ترقية صريحة.
• تتبع ثلاث أرقام: زمن حل الدمج، ساعات إعادة عمل QA، وزمن التصحيح العاجل للإنتاج.
• راجع بعد 2-4 أسابيع وعدِّل.

إذا أردت تقليل ضغط الإصدار للأدوات الداخلية أو بوابات العملاء، يمكن لمنصة لا-كود مثل AppMaster (appmaster.io) أن تساعد أيضًا عن طريق توليد backend وويب وتطبيقات موبايل جاهزة للإنتاج من تصميم بصري. لكنها لا تزال تستفيد من نفس العادات: تغييرات صغيرة، مرشحات QA مثبتة، ومسار ترقية واضح.