نشر ويب جافا:بناء التعليمات البرمجية، أو نشر .war؟

Question

هناك طريقتان رئيسيتان لنشر تطبيق ويب J2EE/Java (بمعنى مبسط للغاية):

نشر القطع الأثرية المجمعة في صندوق الإنتاج

هنا نقوم بإنشاء .war (أو أيًا كان) في مكان آخر، قم بتكوينه للإنتاج (ربما إنشاء العديد من القطع الأثرية للعديد من الصناديق) ووضع القطع الأثرية الناتجة على خوادم الإنتاج.

• الايجابيات:لا توجد أدوات تطوير في صناديق الإنتاج، ويمكن إعادة استخدام القطع الأثرية من الاختبار مباشرة، ولا يحتاج الموظفون الذين يقومون بالنشر إلى معرفة عملية البناء
• سلبيات:عمليتان لإنشاء ونشر القطع الأثرية؛قد يؤدي التكوين المعقد المحتمل للقطع الأثرية المعدة مسبقًا إلى جعل العملية صعبة البرمجة النصية/الأتمتة؛يجب أن إصدار التحف الثنائية

بناء التحف على صندوق الإنتاج

هنا، يتم استخدام نفس العملية المستخدمة يوميًا للإنشاء والنشر محليًا على صناديق المطورين للنشر في الإنتاج.

• الايجابيات:عملية واحدة للمحافظة عليها؛ويتم اختباره/التحقق من صحته بشكل كبير من خلال الاستخدام المتكرر.من المحتمل أن يكون من الأسهل تخصيص التكوين في وقت إنشاء القطعة الأثرية بدلاً من تخصيص الكلمة اللاحقة للقطعة الأثرية المعدة مسبقًا؛لا حاجة لإصدار القطع الأثرية الثنائية.
• سلبيات:أدوات التطوير المعقدة المحتملة اللازمة لجميع صناديق الإنتاج؛يحتاج موظفو النشر إلى فهم عملية البناء؛أنت ليست كذلك نشر ما اختبرته

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

ومع ذلك، فإن تطبيقات Java Enterprise حساسة للغاية للتكوين، ويبدو الأمر كما لو كنت تتساءل عن وجود عمليتين لتكوين العناصر.

أفكار؟

تحديث

إليك مثال ملموس:

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

إذا أردنا استخدام عملية البناء للنشر، فسيكون الأمر يتعلق بإنشاء التكوين الصحيح لبيئة الإنتاج (على سبيل المثال. production.build.properties).

إذا أردنا اتباع "نشر العناصر المجمعة إلى صندوق الإنتاج"، فسنحتاج إلى عملية إضافية لاستخراج خصائص OSCache (غير الصحيحة) واستبدالها بخصائص مناسبة لبيئة الإنتاج.

يؤدي هذا إلى إنشاء عمليتين لإنجاز نفس الشيء.

إذن الأسئلة هي:

• هل يمكن تجنب هذا دون "تجميع الإنتاج"؟
• إذا لم يكن الأمر كذلك، فهل هذا يستحق كل هذا العناء؟هل قيمة "عدم التجميع على الإنتاج" أكبر من "لا تكرر نفسك"؟

Answer 1

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

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

حيث أعمل، تكون عملية النشر لدينا كما يلي.(هذا موجود على Linux، مع Tomcat.)

1. اختبار التغييرات والتحقق من التخريب.(ليس بالضرورة في هذا النظام؛لا نطلب اختبار التعليمات البرمجية الملتزم بها.أنا المطور الوحيد الذي يعمل بدوام كامل، لذا فإن شجرة SVN هي في الأساس فرع التطوير الخاص بي.قد تختلف المسافة المقطوعة.)

2. انسخ ملفات JAR/WAR إلى خادم إنتاج في دليل مشترك يحمل اسم رقم مراجعة Subversion.تتمتع خوادم الويب بحق الوصول للقراءة فقط.

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

تقوم خوادم الويب الخاصة بنا بفك ضغط ملفات WAR على دليل محلي.هذا النهج قابل للتطوير، نظرًا لأن ملفات WAR موجودة على خادم ملف واحد؛يمكن أن يكون لدينا عدد غير محدود من خوادم الويب ونقوم فقط بعملية نشر واحدة.

Answer 2

استخدمت معظم الأماكن التي عملت فيها الطريقة الأولى مع نشر معلومات التكوين الخاصة بالبيئة بشكل منفصل (ونادرًا ما يتم تحديثها) خارج نطاق الحرب/الأذن.

Answer 3

أوصي بشدة "بنشر العناصر المجمعة في صندوق الإنتاج" مثل ملف الحرب.ولهذا السبب يستخدم مطورونا نفس نص البناء (Ant في حالتنا) لبناء الحرب على وضع الحماية التطويري الخاص بهم، كما هو مستخدم لإنشاء القطعة الأثرية النهائية.وبهذه الطريقة يتم تصحيح الأخطاء وكذلك الكود نفسه، ناهيك عن أنه قابل للتكرار تمامًا.

Answer 4

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

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

Answer 5

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

هذا هو ما أعمل حاليًا على إعداده واستخدامه AnthillPro.

يحرر:نحن نستخدم الآن هدسون.موصى بة بشدة!

Answer 6

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

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

تحديث للحصول على مثال ملموس

شيئان يجب مراعاتهما بالنسبة لمثالك.

1. ملف .war هو مجرد ملف .zip بملحق بديل.يمكنك استبدال ملف التكوين الموجود في مكانه باستخدام أدوات Zip القياسية.

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

بشكل عام، أحاول الاحتفاظ بمتطلبات تكوين النشر الخاصة بموقع النشر.

Answer 7

يعد استخدام ملفات الحرب المجمعة 1 لعمليات النشر ممارسة جيدة.
نستخدم النمل لاستبدال القيم المختلفة بين البيئات.نقوم بفحص الملف باستخدام متغير @@@ الذي سيتم استبداله بالبرنامج النصي الخاص بنا.يستبدل البرنامج النصي ant العنصر الصحيح في الملف ثم يقوم بتحديث ملف الحرب قبل النشر لكل منها

<replace file="${BUILDS.ROOT}/DefaultWebApp/WEB-INF/classes/log4j.xml" token="@@@" value="${LOG4J.WEBSPHERE.LOGS}"/>


<!-- update the war file We don't want the source files in the war file.-->
<war basedir="${BUILDS.ROOT}/DefaultWebApp" destfile="${BUILDS.ROOT}/myThomson.war" excludes="WEB-INF/src/**" update="true"/>

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