إصدارات

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

يثبّت الإصدار التزام Git محددًا ويتتبعه عبر بيئاتك، مثل بيئة التجهيز ثم الإنتاج. قد يكون الالتزام موجودًا بالفعل على فرع النشر، أو يمكن لـ 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 request التي فتحها Coroid على شكل مهمتها أو خطتها. يأخذ Coroid في الحسبان ما يعرفه المزوّد والمراجعة التي أجراها بالفعل: الفحوصات، والمراجعات، والحجم، والتعارضات، والملفات التي تعدّلها طلبات سحب متعددة. ويستبعد المسودات، والفحوصات الفاشلة، والتغييرات المطلوبة، وطلبات السحب الواردة من التفرعات، مع توضيح السبب.
3. ألغِ تحديد ما يجب تأجيله، واستخدم الأسهم لتغيير الترتيب؛ حيث يأتي طلب السحب الذي يعتمد على آخر (طلب سحب متداخل من pull request، أو طلب ينص على "يعتمد على #12") دائمًا بعده.
4. اختر إنشاء إصدار. يقوم Coroid بإنشاء Pull Request للإصدار من فرع النشر، ويدمج طلبات السحب بالترتيب، ويفتح طلب سحب واحد للإصدار يسرد ويربط كل منها. release/<version> من فرع النشر، ويدمج طلبات السحب بالترتيب، ويفتح 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. يتم الحصول على النسخة التي أبلغت عنها خطتك، أو، عندما يقوم Coroid بتعيين نسخ المشروع، النسخة التالية (1.4.1 بعد 1.4.0)، ورقم البناء التالي.

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

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

استعادة النظام عند حدوث عطل#

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

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

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

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

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

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

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

ذات صلة#

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