إصدارات

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

يثبّت الإصدار التزام Git واحدًا محددًا ويتابعه عبر بيئاتك، مثل بيئة Staging ثم Production. قد يكون الالتزام موجودًا بالفعل على فرع النشر، أو يمكن لـ Coroid أن يجمع أولًا طلبات السحب المفتوحة في عنصر واحد من نوع pull request للإصدار، ويصبح التزام الدمج فيه هو الإصدار. عند كل محطة، يفحص Coroid الالتزام، ويجمع الموافقات التي تطلبها، ويسجّل عملية النشر التي يُبلغه بها CI/CD. لا يعلن Coroid أن الإصدار قد نُشر اعتمادًا على قوله وحده. بل يجب أن تؤكد ذلك منظومة النشر لديك أو شخص يسجّل عملية نشر خارجية.

فكرة مختصرة في دقيقة واحدة#

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

اطلع على تفاصيل الإصدار بلمحة واحدة#

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

اختر إصدارًا لفتح صفحته.

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

الخطوات الأربع لكل بيئة#

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

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

النشر. عند اكتمال الفحوصات والموافقة، يكون الإصدار جاهزًا للبيئة. إذا كان Coroid متصلًا بـ GitHub Actions أو GitLab CI/CD لتلك البيئة، يختار المالك أو المشرف نشر في… ويبدأ Coroid في تشغيل خط أنابيب النشر للالتزام الدقيق. وإلا، يقوم خط أنابيب النشر الخاص بك بتنفيذ العملية وإبلاغ النتائج. في كلتا الحالتين، لا تتحول الخطوة إلى اللون الأخضر إلا بعد تأكيد النجاح.

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

معنى الحالات المختلفة#

جاهز لا يعني ذلك أبدًا أنه تم نشره. النشر المؤكد فقط هو ما يُحرّك الإصدار قدماً في مسار الإطلاق.

سير العمل#

إعداد إصدارات لمشروع ما#

قم بذلك مرة واحدة لكل مشروع: افتح إصدارات، واختر إعدادات الإصدار، ثم حدد المشروع.

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

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

3. في قسم خط أنابيب النشر، حدد ما إذا كان Coroid هو من يبدأ عمليات النشر أم خط الأنابيب الخاص بك. ثم أنشئ رمز تقرير حتى يتمكن CI/CD من إبلاغ Coroid بما تم نشره.

4. في قسم تحديد الإصدار، حدد مصدر إصدار كل إصدار، وخصص لكل بيئة عنوان URL للإصدار حتى يتمكن Coroid من التأكد من ما يتم تشغيله فيها.

إعدادات الإصدار يُرشدك خلال كل شاشة، و ضَع الإصدار في بناء التطبيق الخاص بك يوضح كيف يصل الإصدار إلى تطبيقك.

إرسال العمل المخطط له#

استخدم هذا عندما تعرف مسبقًا ما الذي يجب إرساله معًا.

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

تجميع طلبات السحب المفتوحة#

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

1. اختر إصدار جديد، واختر المشروع، ثم اختر طلبات السحب المفتوحةتتطلب هذه الخاصية مستودع GitHub أو GitLab، لذا تقوم المشاريع المضيفة بواسطة Coroid بإصدار التزام واحد بدلاً من ذلك.
2. يقوم Coroid بسرد pull requests المفتوحة في فرع النشر، وذلك بترتيب الأمان الأول. يظهر pull request الذي فتحه Coroid كمهمة أو خطة له. يقوم Coroid بتقييم ما تعرفه أداة التوفير وعمليات المراجعة الخاصة به، مثل الفحوصات والمراجعات والحجم والتعارضات والملفات التي تؤثر عليها عدة pull requests. كما يستبعد المسودات والفحوصات الفاشلة والتغييرات المطلوبة وpull requests القادمة من فروع خارجية، مع توضيح الأسباب.
3. ألغِ تحديد ما يجب تأجيله، واستخدم الأسهم لتغيير الترتيب. pull request الذي يعتمد على آخر (stacked pull request، أو الذي ينص على "يعتمد على #12") يأتي دائمًا بعده.
4. اختر إنشاء إصدار. يقوم Coroid بإنشاء release/<version> من فرع النشر، ثم يدمج pull requests بالترتيب المحدد، ويفتح pull request للإصدار يسرد روابط كل منها.
5. إذا كان هناك تعارض بين pull request وفرع الإصدار، فإن التجميع خطوة تتوقف عند هذا الحد وتعرض الملفات. اختر حل عبر Coroid للسماح لوكيل المطور بدمجها وحل التعارض ضمن مهمة، أو تجاهله لمتابعة العمل بدونه.
6. راجع pull request للإصدار وادمجه مع التزام الدمج. ثم يضع مزوّد الخدمة علامة الدمج على كل pull request المجمّعة. وتثبّت Coroid التزام الدمج بوصفه التزام الإصدار، وتسجّل طلبات السحب المجمّعة بوصفها ما سيتم شحنه، وتغلق أي طلبات لا تزال مفتوحة مع رابط إلى pull request للإصدار.
7. اتبع الخطوات الأربع لكل بيئة كما هو معتاد.

تعمل عمليات الدمج باستخدام أمر squash أو rebase أيضًا، لكن مزودك لا يُعلن عن دمج طلبات السحب الأصلية. بدلاً من ذلك، تقوم Coroid بإغلاقها مع تعليق.

إرسال ما يوجد في الفرع الرئيسي#

استخدم هذا للتسليم المستمر، عندما ترسل كل ما تم دمجه.

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

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

إرسال إصلاح عاجل#

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

استعادة الوضع عند حدوث خلل#

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

من الدردشة أو محررك#

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

إصدار عدة مشاريع معًا#

تجمع قطارات الإصدارات إصدارات من عدة مشاريع يجب شحنها معًا وبترتيب معين، مثل API والتطبيق الذي يعتمد عليه. اطلع على عمليات استعادة وقطارات الإصدارات.

ما يفعله Coroid وما لا يفعله#

• تقوم Coroid بتثبيت الالتزامات وإجراء الفحوصات وتسجيلها. بينما يقوم المستودع الخاص بك وCI/CD ببناء البرمجيات ونشرها.
• عندما تقوم بتجميع pull requests، تنشئ Coroid فرع الإصدار وpull request للإصدار. لكنها لا تقوم بدمج pull request للإصدار نيابة عنك.
• لا تبدأ Coroid خط أنابيب النشر إلا عندما تقوم بتوصيله ويطلب مالك أو مشرف نشر البرمجيات.
• طلب النشر ليس دليلًا كافيًا. لا يتحرك مسار الإطلاق إلا بعد تأكيد نجاح عملية النشر عبر خط الأنابيب أو بعد تسجيل نشر خارجي تم التحقق منه.
• ملاحظات الإصدار عبارة عن مسودات تقوم أنت بتحريرها والموافقة عليها. ولا تقوم Coroid بنشرها في أي مكان.
• دورة العمل هي فترة تخطيط، وليست حدًا لنشر البرمجيات. يمكن لدورة عمل واحدة أن تغذي عدة إصدارات، ويمكن لإصدار واحد أن يحتوي على عمل من عدة دورات عمل.

ذات صلة#

• إعدادات الإصدار
• أحداث النشر وإعدادات CI
• وضع الإصدار في بناءك
• عمليات استعادة وقطارات الإصدارات
• دورات عمل
• المهام والخطط ودورات العمل والمسارات
• أدلة الجودة والمراجعة