Skip to main content
توضح هذه الوثيقة كيفية ترقية عملية نشر Teable ذاتية الاستضافة.

قنوات الإصدار ووسوم الإصدارات

ينشر تطبيق Teable وسوم إصدارات مستندة إلى التاريخ بالصيغة release.<timestamp>.<build> (مثل release.2026-07-14T12-24-39Z.2228)، بالإضافة إلى قناتين عائمتين: تصدر الإصدارات بوتيرة متكررة (غالبًا عدة مرات أسبوعيًا)، وأنت تقرر موعد الترقية. ترد جميع الوسوم في GitHub Packages.
قبل تنفيذ أي ترقية، نوصي بشدة بإنشاء نسخة احتياطية من بياناتك أولًا.

التحديثات الدورية: اتبع سجل التغييرات

يُعلن عن الميزات والإصلاحات الجديدة في سجل التغييرات، ويحمل كل وسم إصدار من Teable تاريخ بنائه، ولذلك فإن معرفة ما إذا كانت ميزة ما متاحة لديك لا تتطلب سوى مقارنة التواريخ. للحصول على ميزة قرأت عنها، انقل صورة Teable إلى أي إصدار بتاريخ يوافق تاريخ ذلك الإدخال أو يليه:
  • يمكن لعمليات النشر باستخدام Docker أن تتبع قناة latest ببساطة:
    يُعاد إنشاء الحاويات باستخدام الصورة الجديدة؛ وتظل بياناتك في وحدات تخزين Docker (أو قاعدة بياناتك الخارجية) دون مساس.
  • ينبغي ألا تستخدم عمليات النشر باستخدام Kubernetes وسمًا عائمًا: أبقِ صورة Teable مثبتة على وسم محدد، وحدّث الوسم المثبت عمدًا مع كل تحديث. يحل البرنامج النصي pin-image.sh في مستودع النشر الإصدار المحدد الذي تشير إليه latest حاليًا.

أفضل الممارسات: ترقية المنصة كاملةً معًا

تتضمن عملية النشر متكاملة الميزات مساري إصدار: تطبيق Teable والمنصة نفسها (راجع البنية). ويربط النهج الدوري الأكثر موثوقية بينهما، مع استخدام VERSIONS.md ورقةً للترقية. في كل جولة:
  1. رقِّ طبقة التشغيل إلى أحدث إصدار للمنصة (v<year>.<month>.<seq>): يمثل كل وسم git لقطة موثّقة لجميع مكونات وقت التشغيل، ويوضح إدخال CHANGELOG.md الخاص به ما تغير وما يجب عليك فعله، إن وُجد (يمكن استبدال معظم الإصدارات أثناء التشغيل). اعمل من نسخة المستودع المسحوبة عند ذلك الوسم.
  2. انقل تطبيق Teable إلى وسم الإصدار المحدد الذي تشير إليه latest حاليًا (يحلّه pin-image.sh) — أي إلى تركيبة مثبتة وموثّقة بدلًا من قناة عائمة.
  3. شغّل أداة doctor المضمنة — فهي تتحقق من السلامة وتقارن ما يعمل فعليًا ببيان إصدار المنصة (متوافق / يجب ترقية تطبيق Teable / تركيبة غير معروفة).

الأسرار المطلوبة

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

ترحيل قاعدة البيانات

ينفذ Teable عمليات ترحيل قاعدة البيانات تلقائيًا عند بدء التشغيل؛ ولا يلزم أي إجراء يدوي. إذا بدا أي شيء غير صحيح بعد الترقية، فتحقق من السجلات:

التراجع

إذا واجهت مشكلات بعد الترقية:
  1. أعد وسم الصورة في docker-compose.yaml إلى وسم الإصدار السابق (لهذا يتفوق تثبيت الإصدار على latest: فالإصدار السابق يكون مدوّنًا).
  2. docker compose up -d
قد لا يكون التراجع بعد إصدار رحّل مخطط قاعدة البيانات آمنًا — استعد نسختك الاحتياطية السابقة للترقية في هذه الحالة. وهذا هو السبب الرئيسي وراء التوصية بالنسخ الاحتياطي أعلاه.

الأسئلة الشائعة

لا. تُخزن بياناتك في وحدات تخزين Docker أو قواعد بيانات خارجية، ولن تؤثر ترقية الحاويات في بياناتك. ومع ذلك، نظل نوصي بإنشاء نسخة احتياطية قبل الترقية.
لا. يظل معرّف النسخة دون تغيير أثناء تحديثات التطبيق. فهو معرّف دائم لعملية التثبيت ذاتية الاستضافة.
يستغرق سحب الصور الجديدة عادةً بضع دقائق (بحسب سرعة الشبكة)، ولا تستغرق إعادة تشغيل الحاويات سوى بضع ثوانٍ. وتكتمل العملية بأكملها عادةً في غضون 5 إلى 10 دقائق.
عند استخدام docker compose up -d، يحدث انقطاع وجيز في الخدمة (عادةً من بضع ثوانٍ إلى عشرات الثواني).
يمكنك التحقق من الإصدار الحالي عبر:
  • عرض رقم الإصدار في أسفل يسار واجهة Teable
  • استخدام حساب مسؤول للوصول إلى لوحة الإدارة
  • تنفيذ docker inspect <container> --format='{{.Config.Image}}' للتحقق من إصدار الصورة. إذا كنت تستخدم قناة latest، فتتضمن عملية النشر متكاملة الميزات أداة مساعدة باسم pin-image.sh تحل الإصدار الذي تشير إليه latest حاليًا.
  1. تحقق أولًا من سجلات الحاوية لاستكشاف الأخطاء وإصلاحها: docker compose logs teable
  2. إذا كانت المشكلة متعلقة بترحيل قاعدة البيانات، فحاول الاستعادة من النسخة الاحتياطية
  3. إذا استمرت المشكلة، فتراجع إلى الإصدار السابق
  4. تواصل مع الدعم عبر support@teable.ai
آخر تعديل في ٤ سبتمبر ٢٠٢٦