الإصدارات

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

لمحة عامة

نطلق باستمرار ثلاثة مكونات رئيسية:

• تويست CLI - أداة سطر الأوامر - أداة سطر الأوامر
• خادم تويست - الخدمات الخلفية - الخدمات الخلفية
• تطبيق تويست - تطبيقا macOS و iOS (يتم نشر تطبيق iOS فقط بشكل مستمر على TestFlight، انظر المزيد [هنا] (#app-store-release)

كل مكوّن لديه خط إصدار خاص به يعمل تلقائيًا عند كل دفعة إلى الفرع الرئيسي.

كيف تعمل

1. الالتزام بالاصطلاحات

نحن نستخدم [الالتزامات التقليدية] (https://www.conventionalcommits.org/) لهيكلة رسائل الالتزام الخاصة بنا. وهذا يسمح لأدواتنا بفهم طبيعة التغييرات، وتحديد نتوءات الإصدار، وإنشاء سجلات التغيير المناسبة.

التنسيق: النوع (النطاق): الوصف

أنواع الالتزامات وتأثيرها

النوع	الوصف	تأثير الإصدار	مثال على ذلك
الفذ	ميزة أو قدرة جديدة	نتوء الإصدار البسيط (x.Y.z)	الميزة (cli): إضافة دعم ل Swift 6
إصلاح	إصلاح الخلل	نتوء إصدار التصحيح (x.y.Z)	إصلاح (التطبيق): حل مشكلة التعطل عند فتح المشاريع
المستندات	تغييرات التوثيق	لا يوجد إصدار	المستندات: دليل تثبيت التحديث
النمط	تغييرات نمط الكود	لا يوجد إصدار	النمط: تنسيق الرمز باستخدام سويفت فورمات
إعادة البناء	إعادة هيكلة التعليمات البرمجية	لا يوجد إصدار	إعادة هيكلة (الخادم): تبسيط منطق المصادقة
الكمال	تحسينات الأداء	نتوء إصدار التصحيح	بيرف(cli): تحسين دقة التبعية
الاختبار	اختبار الإضافات/التغييرات	لا يوجد إصدار	الاختبار: إضافة اختبارات الوحدة للتخزين المؤقت
العمل الروتيني	مهام الصيانة	لا يوجد إصدار	العمل الروتيني: تحديث التبعيات
ci	تغييرات CI/CDD	لا يوجد إصدار	ci: إضافة سير عمل للإصدارات

التغييرات العاجلة

تؤدي التغييرات الخارقة إلى رفع الإصدار الرئيسي (X.0.0) ويجب الإشارة إليها في نص الالتزام:

feat(cli): change default cache location

BREAKING CHANGE: The cache is now stored in ~/.tuist/cache instead of .tuist-cache.
Users will need to clear their old cache directory.

2. اكتشاف التغيير

يستخدم كل مكوّن [git cliff] (https://git-cliff.org/) لـ

• تحليل الالتزامات منذ الإصدار الأخير
• تصفية الالتزامات حسب النطاق (cli، التطبيق، الخادم)
• تحديد ما إذا كانت هناك تغييرات قابلة للإصدار
• إنشاء سجلات التغيير تلقائياً

3. خط أنابيب الإصدار

عندما يتم اكتشاف تغييرات قابلة للإزالة:

1. حساب الإصدار: يحدد خط الأنابيب رقم الإصدار التالي
2. إنشاء سجل التغييرات: يقوم git cliff بإنشاء سجل تغييرات من رسائل الالتزام
3. عملية البناء: تم بناء المكون واختباره
4. إنشاء الإصدار: يتم إنشاء إصدار GitHub مع القطع الأثرية
5. التوزيع: يتم دفع التحديثات إلى مديري الحزم (على سبيل المثال، Homebrew لـ CLI)

4. تصفية النطاق

لا يصدر كل مكون إلا عندما يكون لديه تغييرات ذات صلة:

• CLI: الالتزامات مع (cli) النطاق أو بدون نطاق
• التطبيق: الالتزامات مع (التطبيق) النطاق
• الخادم: الالتزامات مع (الخادم) النطاق

كتابة رسائل التزام جيدة

نظرًا لأن رسائل الالتزام تؤثر بشكل مباشر على ملاحظات الإصدار، فمن المهم كتابة رسائل واضحة ووصفية:

افعل ذلك:

• استخدم الفعل المضارع: "إضافة ميزة" وليس "إضافة ميزة"
• كن موجزًا ولكن وصفيًا
• قم بتضمين النطاق عندما تكون التغييرات خاصة بالمكونات
• المشكلات المرجعية عند الاقتضاء: إصلاح (cli): حل مشكلة إنشاء ذاكرة التخزين المؤقت (#1234)

لا تفعل

• استخدم رسائل غامضة مثل "إصلاح الخلل" أو "تحديث الكود"
• مزج عدة تغييرات غير مرتبطة في التزام واحد
• نسيت تضمين معلومات التغييرات الفورية

التغييرات العاجلة

بالنسبة للتغييرات القاطعة، قم بتضمين BREAKING CHANGE: في نص الالتزام:

feat(cli): change cache directory structure

BREAKING CHANGE: Cache files are now stored in a new directory structure.
Users need to clear their cache after updating.

عمليات سير عمل الإصدار

يتم تعريف سير عمل الإصدار في:

• .github/workflows/cli-release.yml - إصدارات CLI
• .github/workflows/app-release.yml - إصدارات التطبيق
• .github/workflows/server-release.yml - إصدارات الخادم

كل سير عمل:

• يعمل على الدفع إلى الرئيسي
• يمكن تشغيله يدوياً
• يستخدم جرف git كليف لاكتشاف التغييرات
• يتعامل مع عملية الإصدار بالكامل

مراقبة الإصدارات

يمكنك مراقبة الإصدارات من خلال:

• صفحة إصدارات GitHub
• علامة تبويب إجراءات GitHub لتشغيل سير العمل
• ملفات Changelog في كل دليل مكون

المزايا

يوفر نهج الإصدار المستمر هذا:

• تسليم سريع: تصل التغييرات إلى المستخدمين مباشرة بعد الدمج
• تقليل الاختناقات: لا انتظار للإصدارات اليدوية
• اتصال واضح: سجلات التغيير التلقائية من رسائل الالتزام
• عملية متسقة: تدفق الإصدار نفسه لجميع المكونات
• ضمان الجودة: يتم إصدار التغييرات التي تم اختبارها فقط

استكشاف الأخطاء وإصلاحها

إذا فشل الإصدار

1. تحقّق من سجلات إجراءات GitHub لسير العمل الفاشل
2. تأكد من أن رسائل الالتزام الخاصة بك تتبع التنسيق التقليدي
3. التحقق من اجتياز جميع الاختبارات
4. تحقق من بناء المكوّن بنجاح

بالنسبة للإصلاحات العاجلة التي تحتاج إلى إصدار فوري:

1. تأكد من أن التزامك له نطاق واضح
2. بعد الدمج، راقب سير عمل الإصدار بعد الدمج
3. إذا لزم الأمر، قم بتشغيل الإصدار اليدوي

إصدار متجر التطبيقات

في حين أن CLI والخادم يتبعان عملية الإصدار المستمر الموضحة أعلاه، فإن تطبيق iOS هو استثناء بسبب عملية مراجعة متجر تطبيقات Apple App Store:

• الإصدارات اليدوية: تتطلب إصدارات تطبيقات iOS إرسالها يدويًا إلى متجر التطبيقات
• تتأخر المراجعة: يجب أن يخضع كل إصدار لعملية مراجعة Apple، والتي قد تستغرق من يوم إلى 7 أيام
• التغييرات المجمعة: عادةً ما يتم تجميع تغييرات متعددة معًا في كل إصدار من إصدارات iOS
• TestFlight: قد يتم توزيع الإصدارات التجريبية عبر TestFlight قبل إصدار App Store
• ملاحظات الإصدار: يجب أن تكون مكتوبة خصيصًا لإرشادات متجر التطبيقات

لا يزال تطبيق iOS يتبع نفس اصطلاحات الالتزام ويستخدم git cliff لإنشاء سجل التغيير، ولكن الإصدار الفعلي للمستخدمين يحدث وفق جدول زمني يدوي أقل تواتراً.