ما هي أفضل طريقة للترقية من جانغو 0.96 إلى 1.0؟

StackOverflow https://stackoverflow.com/questions/128466

  •  02-07-2019
  •  | 
  •  

سؤال

هل يجب أن أحاول فعليًا ترقية تطبيقي الحالي، أو مجرد إعادة كتابته من الصفر في الغالب، مع حفظ الأجزاء (القوالب، وما إلى ذلك) التي يمكنني حفظها؟

هل كانت مفيدة؟

المحلول

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

  1. تغييرات على بعض العناصر غير التقليدية في النماذج، مثل بناء الجملة الخاص باتباع المفاتيح الخارجية.

  2. مجموعة صغيرة من التغييرات في القالب، أبرزها الهروب التلقائي.

  3. أي شيء يعتمد على البنية المحددة للأجزاء الداخلية لـ Django.لا ينبغي أن تكون هذه مشكلة إلا إذا كنت تفعل أشياء مثل التعديل الديناميكي لأجزاء Django الداخلية لتغيير سلوكها بطريقة ضرورية/مناسبة لمشروعك.

باختصار، ما لم تكن تقوم بالكثير من الأشياء الغريبة و/أو المعقدة، فإن الترقية البسيطة يجب أن تكون غير مؤلمة نسبيًا وتتطلب فقط بعض التغييرات.

نصائح أخرى

يرقي.بالنسبة لي كان الأمر بسيطًا جدًا:يتغير __str__() ل __unicode__(), ، اكتب الأساسية admin.py, ، وتم.ما عليك سوى البدء في تشغيل تطبيقك على الإصدار 1.0، واختباره، وعندما تواجه خطأً، استخدم الوثائق الموجودة على التغييرات غير المتوافقة مع الوراء لمعرفة كيفية حل المشكلة.

فقط قم بترقية تطبيقك.كان التحول من 0.96 إلى 1.0 ضخمًا، ولكن فيما يتعلق بالتغييرات غير المتوافقة مع الإصدارات السابقة، أشك في أن تطبيقك يحتوي على 10% منها.

كنت على صندوق السيارة قبل إصدار Django 1.0، لذلك كان الانتقال بالنسبة لي بمرور الوقت، ولكن حتى في ذلك الوقت كانت الأشياء الرئيسية الوحيدة التي كان علي تغييرها هي الأشكال الجديدة، وnewforms-admin، شارع() ل يونيكود() وmaxlength إلى max_length

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

من السهل ترقية أبسط المواقع فقط.

توقع ألمًا حقيقيًا إذا كان موقعك موجودًا غير ASCII جزء من العالم (اقرأ:في أي مكان خارج الولايات المتحدة الأمريكية والمملكة المتحدة).كان التغيير الأكثر إيلامًا في Django هو التبديل من bytestrings إلى كائنات unicode داخليًا - الآن عليك العثور على جميع الأماكن التي تستخدم فيها سلاسل بايت وتغييرها إلى unicode.أسوأ حالة هي عرض القالب، فلن تعرف أبدًا أنك نسيت تغيير متغير واحد حتى تحصل على UnicodeError.

شيء آخر ملحوظ:المتلاعبين (com.oldforms) لقد اختفى وليس لديك طريقة أخرى سوى إعادة كتابة جميع الأجزاء باستخدام النماذج (newforms).

إذا كانت هذه هي حالتك وكان مشروعك أكبر من 2-3 تطبيقات، فسأكون مترددًا في الترقية حتى يكون ذلك ضروريًا حقًا.

لقد قمنا بالترقية في عملية متعددة الخطوات وأنا سعيد جدًا بذلك.كان التطبيق المعني حوالي 100.000 LoC ويقوم بتشغيل العديد من وظائف الأعمال الأساسية مع الكثير من التفاعل مع الأنظمة القديمة.لقد عملنا هكذا:

  1. تحديث إلى Django 0.97-Post Unicode دمج.إصلاح كافة مشاكل يونيكود
  2. Refactor التطبيق في تطبيقات قابلة لإعادة الاستخدام ، أضف الاختبارات.تركنا ذلك مع 40.000 LOC في التطبيق/المشروع الرئيسي
  3. الترقية إلى دمج Django 0.97-post autoexcape.إصلاح الهروب التلقائي في التطبيقات القابلة لإعادة الاستخدام التي تم إنشاؤها في 3.ثم قم بإصلاح مشكلات الهروب التلقائي المتبقية في تطبيق mian.
  4. الترقية إلى 1.0.ما تبقى هو في الغالب إصلاح الأمور الإدارية.

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

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

وبشكل عام أنا راض تماما عن النتيجة.لدينا الآن قاعدة بيانات أفضل بكثير لمزيد من التطوير.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top