انتهاء دعم Atlassian Connect في 31 يناير 2027: نقل تطبيقات Jira وConfluence المخصصة إلى Forge

في 31 يناير 2027 تنهي Atlassian دعم Connect، وهو الإطار الذي بُنيت عليه معظم تطبيقات Jira وConfluence Cloud الأقدم. ومن ذلك اليوم، تقول Atlassian إنها "لن تعالج إلا الثغرات الأمنية الحرجة في Connect"، وإن التطبيق الخاص الذي لا يزال يعمل على Connect "لن يكون مدعوماً بعد ذلك وقد يتوقف عن العمل بشكل صحيح".

إن كانت كل التطبيقات على موقعك قد جاءت من Atlassian Marketplace، فهذا عمل المورّدين، ومعظمهم أنجزه: فقد أعلنت Atlassian في أغسطس 2026 أن "أكثر من 95% من مقاعد التطبيقات المدفوعة رُحّلت إلى Forge".

هذا المقال للحالة الأخرى. لدى شركتك تطبيق Jira أو Confluence بناه لك أحدهم: مطور داخلي، أو مقاول، أو شريك. ثُبّت عبر رابط، ولم يُشترَ. لن ينقله أحد من خارج شركتك، وقد لا يكون الشخص الذي كتبه موجوداً بعد الآن.

ما الذي يعنيه انتهاء الدعم، وما الذي لا يعنيه

لا يوجد تاريخ إيقاف منشور. لم تقل Atlassian إن تطبيقات Connect ستتوقف عن العمل في 1 فبراير 2027، وإعلان الجدول الزمني الأصلي قال إن "العملاء الذين لديهم تطبيقات Connect مثبتة لن يفقدوا الوصول إلى التطبيق".

لا تقرأ ذلك كضمانة. ما يتغير هو أن أحداً في Atlassian لم يعد يرعى Connect:

• لا تُصلح سوى الثغرات الأمنية الحرجة. والأخطاء غير الحرجة تبقى.
• "ستحدث عمليات إهمال ميزات Connect بإشعار قصير."
• لن يتمكن دعم Atlassian "من إصلاح المشكلات الناتجة عن تلك التقنية القديمة".
• وبعبارة Atlassian نفسها: "لن يبقى Connect في حالة مستقرة بعد انتهاء الدعم. ستزداد الأعطال وستتسع فجوات التوافق."

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

ما الذي حدث بالفعل

موعد يناير هو آخر خطوة في تسلسل بدأ في 2025.

• سبتمبر 2025: توقف Marketplace عن قبول تطبيقات Connect الجديدة.
• 31 مارس 2026: جُمّدت التحديثات. وكانت إرشادات Atlassian للتطبيقات المخصصة واضحة: بعد ذلك التاريخ "لن تتمكن بعد ذلك من دفع تحديثات إلى تطبيقات Connect". فالشيفرة على خادمك لا تزال ملكك تغيّرها كما تشاء، لكن ما يعلنه التطبيق لـ Jira أو Confluence (وحداته، ونطاقات صلاحياته، وخطافات الويب) ثابت.
• مارس 2026: قال الجدول الزمني أيضاً إن "إمكانية تثبيت تطبيقات Connect خاصة جديدة عبر Connected Apps ستصبح غير متاحة". اعتبر إلغاء التثبيت طريقاً باتجاه واحد: لا تُزل تطبيق Connect خاصاً لمجرد أن ترى ما الذي ينكسر.
• أغسطس 2026: نقلت Atlassian انتهاء الدعم من ديسمبر 2026 إلى 31 يناير 2027. أي شهر إضافي واحد. لا تخطط لتمديد آخر.
• الآن: تنشر Atlassian تحذيرات في Atlassian Administration، حيث تُوسم التطبيقات الخاصة التي لا تزال على Connect "بحالة LEGACY".

العثور على تطبيقاتك الخاصة

ابدأ في Atlassian Administration، في صفحة Connected Apps. كل ما يحمل الوسم LEGACY يعمل على Connect. وقائمة التحقق لدى Atlassian لتمييز التطبيق الخاص: إن صحّ معظم ما يلي، فنقله مسؤوليتك:

• ثُبّت عبر رابط مباشر أو وضع المطور، لا من Marketplace؛
• غير ظاهر في البحث على Marketplace؛
• مؤسستك هي من يصون الشيفرة المصدرية؛
• لا معلومات ترخيص، ومؤسستك هي الوحيدة المدرجة تحت التثبيتات؛
• لا يوجد شريط جانبي للروابط ذات الصلة في صفحته على Connected Apps (تطبيقات Marketplace لها واحد).

وتضيف Atlassian قاعدة تقريبية: التطبيق السحابي المخصص الذي بُني قبل أكثر من خمس سنوات هو على الأرجح تطبيق Connect، وتطبيقات Connect مستضافة خارج Atlassian، "عادة على خدمة مثل Heroku أو AWS أو Azure أو Google Cloud Platform". ويُظهر رابط View app details في التطبيق من هو المطور، بحسب ما تعرفه Atlassian.

لكل تطبيق، دوّن خمسة أمور قبل أن يلمس أحد الشيفرة:

1. ماذا يفعل ومن يستخدمه، في جملة يتعرّف عليها مالك من جهة الأعمال.
2. أين الشيفرة المصدرية. مستودع تتحكم فيه، أو حاسوب محمول لمقاول، أو لا مكان.
3. أين يعمل، ومن يدفع تكلفة الاستضافة من حسابه. إن كان الخادم على حساب سحابي لمقاول سابق، فهذا خطر اليوم، لا في يناير.
4. الواصف (descriptor). كل تطبيق Connect يقدّم ملف atlassian-connect.json عبر رابط. وهو يسرد كل وحدة ونطاق صلاحيات وwebhook يستخدمه التطبيق، ما يجعله أدق حصر ستحصل عليه.
5. ما البيانات التي يحتفظ بها، وأين: في قاعدة بياناته الخاصة، أم في خصائص مخزَّنة على تذاكر Jira وصفحات Confluence.

قرّر قبل أن تبني

ليس كل تطبيق خاص يستحق الترحيل. نصيحة Atlassian نفسها هي التحقق مما إذا كانت ميزة أصلية في Jira أو Confluence تؤدي المهمة الآن، وألا ترحّل إلا ما لا تزال المؤسسة تحتاج إليه. فالتطبيقات القديمة كثيراً ما سدّت فجوة أغلقها المنتج منذ ذلك الحين.

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

ما الذي يتضمنه الانتقال إلى Forge

Forge ليس Connect باسم جديد. فنموذج الاستضافة، ونموذج الأمان، ونموذج واجهة المستخدم كلها مختلفة، ولهذا تنصح Atlassian حتى أصحاب التطبيقات البسيطة ببدء إثبات مفهوم مبكراً.

الاستضافة

تطبيق Connect خدمة ويب تشغّلها أنت. أما تطبيق Forge فيعمل على بنية Atlassian التحتية في صورة دوال بحدود صارمة: 25 ثانية للدالة التي يُطلقها المستخدم، وحتى 900 ثانية للأحداث غير المتزامنة والمشغّلات المجدولة. فتطبيق Connect الذي يشغّل مزامنة مدتها عشر دقائق بينما ينتظر المستخدم عليه أن ينقل هذا العمل إلى أحداث غير متزامنة، وكل ما يتجاوز خمس عشرة دقيقة يجب تقسيمه إلى خطوات. والاستدعاءات الخارجية مقيدة أيضاً: أي نطاق غير مُعلن في ملف البيان (manifest) الخاص بالتطبيق يُرفض.

الإبقاء على الخادم الخلفي الذي لديك

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

والمقايضة: قد يجعل Forge Remote التطبيق غير مؤهل لبرنامج Runs on Atlassian. وهذا أقل أهمية لأداة داخلية، لكن يجب أن يقبله فريق الأمن لديك عن وعي.

المصادقة والصلاحيات

تصادق تطبيقات Connect برمز JWT موقَّع بسر مشترك. ويستبدل Forge ذلك بنطاقات OAuth 2.0 مُعلنة في ملف البيان، وبالنسبة للخوادم الخلفية البعيدة، برمز Forge Invocation Token يتحقق منه خادمك بدلاً من JWT.

ثم يُجرى كل استدعاء موثَّق لواجهة Jira أو Confluence إما بصيغة asUser، بصلاحيات الشخص الذي يستخدم التطبيق، وإما بصيغة asApp، التي تعمل بعبارة Atlassian "بصرف النظر عمن يستخدم التطبيق". والمرور على كل استدعاء والاختيار عن قصد هو أهم مراجعة أمنية في الترحيل كله.

وفرق واحد يوقع الفرق في المفاجأة. فوحدات Connect تُعرض للمستخدمين غير المرخصين والمجهولين افتراضياً؛ أما وحدات Forge فلا، ما لم يفعّل ملف البيان ذلك بـ unlicensedAccess. فإن كان تطبيقك يعرض أي شيء لعملاء مكتب الخدمة أو لقرّاء Confluence المجهولين، فاختبر هذا المسار على حدة.

واجهة المستخدم

صفحات Connect إطارات iframe تتواصل مع Jira أو Confluence عبر واجهة JavaScript لدى Atlassian. ويمنحك Forge خيارين:

• UI Kit: إطار مبني على React يعرض مكونات Atlassian الأصلية. سريع ومتسق، لكنك تبني من مكونات Atlassian: قد لا يعمل HTML المخصص، والموارد الثابتة الوحيدة التي يقبلها هي الصور.
• Custom UI: شيفرة HTML وCSS وJavaScript خاصة بك داخل iframe، تتواصل مع المنتج عبر @forge/bridge.

الواجهة الأمامية القائمة على iframe تنتقل عادة إلى Custom UI بأقل التغييرات. أما اللوحات الصغيرة وشاشات الإعدادات فكثيراً ما تكون إعادة بنائها في UI Kit أسرع.

البيانات

هنا تتعثر عمليات الترحيل. لدى Forge تخزين مستضاف خاص به: مخزن مفاتيح وقيم، ومخزن كيانات مخصصة، وForge SQL، ومخزن كائنات في مرحلة المعاينة. والبيانات محصورة لكل تثبيت ومحفوظة في الموقع الجغرافي نفسه لموقع Jira أو Confluence المضيف، فتأتي إقامة البيانات دون إعداد إضافي.

ما يعنيه ذلك لتطبيق خاص:

• البيانات في قاعدة البيانات الخاصة بتطبيق Connect إما تُنقل إلى تخزين Forge بمهمة ترحيل لمرة واحدة، وإما تُترك في مكانها ويُوصل إليها عبر Forge Remote.
• كل ما خزّنه تطبيق Connect على جانب Atlassian تحت مفتاح تطبيقه يجب تصديره ما دام التطبيق القديم يعمل. واختبر مبكراً هل يستطيع التطبيق الجديد قراءته؛ لا تفترض ذلك.
• يحتفظ Forge بالبيانات المستضافة لمدة 28 يوماً بعد إلغاء التثبيت، لكن إعادة التثبيت لا تستعيدها تلقائياً.

اكتب الترحيل كسكربت قابل للتكرار بأعداد يمكنك التحقق منها، وتمرّن عليه على موقع اختبار، واحتفظ بالتصدير.

المسار التدريجي، ولماذا لا يخصك على الأرجح

بنت Atlassian طريقاً ألطف لتطبيقات Connect: اعتماد Forge تدريجياً، مع الإبقاء على التثبيتات القائمة، وتحويل الواصف إلى ملف بيان Forge، ونقل عائلة وحدات واحدة في كل مرة، مع ترحيل بيانات مدمج لبعض الوحدات مثل وحدات الماكرو والحقول المخصصة ومدققات سير العمل.

والعقبة في الفقرة الأولى من الدليل: "الاعتماد التدريجي لـ Forge متاح فقط لتطبيقات Connect الخاصة بـ Confluence وJira المدرجة بالفعل في Marketplace."

بالنسبة لتطبيق خاص، خطط لتطبيق Forge جديد. تنشره في بيئة الإنتاج، وتشاركه مع موقعك عبر رابط تثبيت من وحدة تحكم المطورين، وتشغّله بجانب تطبيق Connect القديم أثناء ترحيل البيانات واختبار المستخدمين، ثم تُزيل تطبيق Connect.

تبقى أدلة الاعتماد مفيدة لمطابقة الوحدات فيها، وكذلك قائمة قدرات Connect غير المتاحة في Forge: فعدة وحدات في Jira Service Management ودعم تطبيق الهاتف موسومة بأنها غير مخطط لها، وjiraReports لا تزال قيد الدراسة. قارن الواصف لديك بتلك القائمة في الأسبوع الأول. فوجود فجوة هناك يغيّر التصميم.

خطة بالعد التنازلي من 31 يناير 2027

من بداية أكتوبر 2026 يبقى نحو سبعة عشر أسبوعاً، وديسمبر قصير على الجميع. خطة تصمد:

1. هذا الأسبوع: اسرد كل تطبيق موسوم بـ LEGACY مع الأمور الخمسة المذكورة أعلاه. وتأكد ممن يتحكم في الشيفرة المصدرية وحساب الاستضافة.
2. بحلول منتصف أكتوبر: قرّر لكل تطبيق: ترحيل، أو استبدال، أو إيقاف. وأبلغ مستخدمي كل ما سيُوقف.
3. بحلول نهاية أكتوبر: إثبات مفهوم على Forge لأصعب جزء في أصعب تطبيق. وعادة يكون ذلك وحدة بلا مقابل مباشر في Forge، أو الوحدة التي تحمل أكبر قدر من البيانات.
4. نوفمبر: البناء، وتشغيل ترحيل البيانات على موقع اختبار أكثر من مرة.
5. بداية ديسمبر: ثبّت تطبيق Forge بجانب تطبيق Connect، ورحّل نسخة من البيانات، ودع من يستخدمونه يومياً يتحققون منه.
6. يناير 2027: الترحيل النهائي، ونقل المستخدمين، وعدم إزالة تطبيق Connect إلا بعد أن يعمل التطبيق الجديد بسلاسة لفترة.

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

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

حين يكون المطور الأصلي قد غادر

تتناول Atlassian هذه الحالة مباشرة. فإن لم تستطع تحديد مالك التطبيق الأصلي أو التواصل معه، أو لم تعد تملك القدرة التطويرية، فهي تقترح الاستعانة بـ Solution Partner. وهي واضحة بالقدر نفسه في أنه دون الشيفرة المصدرية "قد يكون من الضروري إعادة البناء على Forge من الصفر".

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

أين تحصل على المساعدة

نتسلّم شيفرة لم يكتبها أحد في الفريق الحالي، ونفهم ما تفعله حقاً، وننقلها: وبالنسبة لتطبيق Connect يعني ذلك قراءة الواصف والخادم، وبناء تطبيق Forge، وكتابة ترحيل البيانات والتمرّن عليه. وعادة ما يبدأ هذا من عملنا في صيانة الأنظمة القديمة، وإن كان لديك مطورون لكن عددهم لا يكفي، فإن تعزيز الفريق يضيف أشخاصاً إلى فريقك طوال المدة. أخبرنا بما يفعله التطبيق وأين يعمل: راسلنا على office@c9group.dev.