ما هو سير العمل المستند إلى الإصدار؟

مكتمل

هنا، نناقش كيف يمكنك إنشاء سير عمل يستند إلى الإصدار باستخدام GitHub.

ما هو سير العمل المستند إلى الإصدار؟

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

تخطيط العمل مع لوحات مشاريع GitHub

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

الميزة الرئيسية في المشروع هي board. اللوحة هي الخطة المركزية للسجل للتكرار وتحتوي على كافة cards التي يجب حلها. يمكن أن تمثل البطاقة مشكلة أو طلب سحب أو حتى ملاحظة عامة.

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

تعرف على المزيد حول إدارة لوحات المشروع.

يتم دمج حالة مشروع البطاقة عبر المستودع. على سبيل المثال، يؤدي سحب بطاقة من To do إلى In progress إلى تغيير حالتها، وتحديث المؤشر المرئي بجوار عنوان المشروع. يشير المقطع الأخضر إلى قسم البطاقات التي تم وضع علامة عليها Done، بينما يتم استخدام اللون الأرجواني للبطاقات In progress. تمثل المساحة المتبقية كمية البطاقات التي لم تبدأ بعد. بالإضافة إلى سحب البطاقات حول اللوحة، يمكنك تحديثها من طريقة عرضها الرئيسية.

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

تعرف على المزيد حول تتبع تقدم عملك مع لوحات مشاريع.

تتبع مراحل رئيسية محددة

بالنسبة إلى الفرق، أو ربما مجموعات فرعية من الفرق، يقدم GitHub تتبعًا لمرحلة رئيسية.

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

تعرف على المزيد حول تتبع تقدم عملك مع مراحل رئيسية.

تحديد استراتيجية إنشاء إصدارات فرعية

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

تدفق GitHub

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

العمل مع الإصدارات الفرعية الطويلة الأمد

long-lived branch هو الإصدار الفرعي من Git الذي لا يتم حذفه مطلقًا. بعض فرق العمل تفضل تجنبها تماماً لصالح الميزات قصيرة العمر وفروع إصلاح الأخطاء. بالنسبة إلى تلك الفرق، فإن الهدف من أي جهد هو إنتاج طلب سحب يدمج عمله مرة أخرى في main. يمكن أن يكون هذا النهج فعالا للمشاريع التي لا تحتاج أبدا إلى النظر إلى الوراء، مثل تطبيقات الويب التابعة للجهة الأولى التي لا تدعم إصدارا سابقا.

ومع ذلك، هناك بعض السيناريوهات التي يخدم فيها إصدار فرعي طويل الأمد الاهتمامات الأفضل للفريق. الحالة الأكثر شيوعًا لإصدار فرعي طويل الأمد عندما يكون المنتج إصدارات متعددة التي يجب أن تكون معتمدة لفترة طويلة من الوقت. عندما يحتاج فريق ما إلى التخطيط لهذا الالتزام، يجب أن يتبع المستودع اصطلاحًا قياسيًا، مثل release-v1.0، release-v2.0 وهكذا. يجب أيضا وضع علامة على هذه الفروع على أنها محمية في GitHub بحيث يتم التحكم في الوصول للكتابة ولا يمكن حذفها عن طريق الخطأ.

يجب أن تبقى الفرق main كإصدار فرعي جذري ودمج تغييرات الإصدار الفرعي الخاصة بها في المصدر طالما أنها تتناسب مع مستقبل المشروع. عندما يحين الوقت، يجب أن تستند إلى ذلك release-v3.0main بحيث إن تقديم العمل release-v2.0 لا يعقد المستودع.

تقديم خدمة إنشاء إصدارات فرعية طويلة الأمد

افترض أن إصلاح الأخطاء قد تم دمجه في الإصدار الفرعي release-v2.0، ثم دمجه مرة أخرى في مصدر main. ثم اكتشف لاحقا أن هذا الخطأ موجود أيضا في release-v1.0 الفرع ويجب إعادة إرسال التصحيح للعملاء الذين لا يزالون يستخدمون هذا الإصدار. ما هي أفضل طريقة لدعم هذا الإصلاح؟

لن يكون دمج main الفرع لأسفل release-v1.0 خيارا ممكنا، لأنه سيحتوي على عدد كبير من التثبيتات التي لم يكن المقصود منها أن تكون جزءا من هذا الإصدار. لنفس السبب، لن يكون إعادة الاعتماد release-v1.0 على التثبيت الحالي main خيارا.

وهناك خيار بديل هو إعادة تنفيذ الإصلاح على الإصدار الفرعي release-v1.0 يدويًا، ولكن هذا النهج يتطلب الكثير من إعادة العمل ولا يتم قياسه بشكل جيد عبر إصدارات متعددة. ومع ذلك، تقدم Git حلاً تلقائيًا لهذه المشكلة في شكل أمر cherry-pick لديها.

ما هو أمر Git لاختيار الكرز؟

git cherry-pick هو أمر يمكّنك من تطبيق عمليات تثبيت معينة من إصدار فرعي إلى آخر. إنها ببساطة تكرر عمليات تثبيت محددة وتطبّقها على الإصدار الفرعي المستهدف كعمليات تثبيت جديدة. إذا لزم الأمر، يمكن للمطورين دمج أي تعارضات قبل الإصلاح.

تعرف على المزيد حول اختيار كرز من Git.

إنشاء إصدارات للمستهلكين

عندما يكون إصدار المنتج جاهزًا للإصدار، يقوم GitHub بتبسيط عملية حزمها وإعلام المستهلكين.

إنشاء إصدار هو مباشرة مثل ملء النموذج:

• أدخل علامة Git لتطبيقها، والتي يجب أن تتبع تعيين الإصدار دلاليًا، مثل v1.0.2. GitHub تدير عملية إنشاء علامة Git التي تحددها.
• أدخل اسمًا للإصدار الخاص بك. بعض الممارسات الشائعة هي:
  • استخدم اسماً وصفياً
  • استخدم إصدار Git
  • استخدام ملخص موجز لكيفية تغيير الإصدار منذ الإصدار السابق
  • استخدم اسماً رمزياً أو عبارة عشوائية
• توفير ملاحظات حول الإصدار. يمكنك أتمتة هذه المهمة باستخدام تطبيق "مسودة الإصدار"، الذي يحلل التغييرات منذ الإصدار السابق ويتضمن عناوين طلب السحب المقترنة.
• إذا كنت ترغب في توفير ملفات كجزء من الإصدار، مثل المثبتات التي تم إنشاؤها مسبقا، يمكنك سحبها وإفلاتها في النموذج. لا تحتاج إلى حزم المصدر حيث يعالج GitHub ذلك لك تلقائيًا.
• الإشارة إلى ما إذا كان الإصدار إصدارا مسبقا عن طريق تحديد هذا المربع. تساعد هذه الإشارة العملاء على تجنب الإصدارات التجريبية إذا أرادوا ذلك.

بمجرد نشر الإصدار، يتلقى كل شخص يشاهد المستودع إشعارا.

تعرف على المزيد حول إصدارات GitHub.