نحن نطلق مشروع Java مع Maven بطريقة جديدة

لقد اعتدنا جميعًا منذ فترة طويلة على Maven ، لإصدارها وإدارة التبعية. ولد مافن عندما كان التجميع اليومي للمشروع هو الأكثر جرأة ، عندما كان من الطبيعي أن يتم إطلاقه مرتين على الأقل في السنة ، ثم أطلق على جنكينز اسم هدسون ، وكانت الأشجار كبيرة ...

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

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

كل هذا سهّل بشكل كبير التطوير ، وبدء المشاريع الجديدة ، وإدخال المطورين إلى المشروع ، وإصدار النسخة وإدارة التبعية.

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

بعد ذلك ، سنحاول تغيير العالم نحو الأفضل وتبسيط حياتنا.

تنويه
أفترض أن القارئ على دراية بـ Java و Maven ودورة حياة التطوير وتكوين CI / CD ، ويفهم لماذا يحتاج كل هذا وحتى النينجا .

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

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

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

عند استخدام المخضرم مع المكوّن الإضافي للإصدار ، تظهر ميزة أخرى مثيرة للاهتمام: لا يتم إجراء إعادة البناء بنفس مجموعة الأوامر مثل الإصدار الأصلي.

ربما تبدو كل هذه المشاكل بعيدة المنال بالنسبة لشخص ما ، ولكن مع وجود عدد كبير إلى حد ما من المشاريع ، فإن إدارة وتكوين CI / CD تتحول إلى عملية مزعجة ومربكة للغاية.

الآن بعد أن ظهرت المشكلة ، دعنا نحاول حلها ، حتى لا نغير مجموعة الأدوات والعمليات ، وبشكل عام هي نفسها بطريقة أو بأخرى.

المطلوب:

  • يتم تخزين الإصدار مرة واحدة ، كعلامة مستودع
  • من الممكن إعادة بناء أي إصدار ، يجب أن تكون مجموعة الخطوات هي نفسها كما في حالة الإصدار الجديد
  • لا تحتاج إلى أذونات الكتابة إلى المستودع
  • ما زلنا نستخدم مخضرم كمدير للمشروع

افترض أن CI / CD سيحصل على علامة لنا وسحب مشروع.

افترض أن العلامة الخاصة بنا مليئة بـ CI / CD في متغير البيئة RELEASE_TAG ، ومن أجل تحرير الإصدار ، يجب علينا تنفيذ الأوامر التالية:

mvn -B versions:set -DnewVersion=$RELEASE_TAG (1) mvn -B deploy (2) 

1- تحديث النسخ في ملفات pom للمشروع ووحداته
2 - يبني ، وإذا تم تكوين المشروع بشكل صحيح ، فإنه يقوم بتحميل التحف إلى المستودع

لا تنس تعيين علامة -B ، وإلا سيتحول سجل التنفيذ إلى قرع.

هام: لتجنب الارتباك وإظهار كيفية ومكان التجميع بوضوح ، تحتاج إلى تثبيت إصدار المشروع في شيء مجرد ، على سبيل المثال DEVELOPMENT-SNAPSHOT. يمكنك استخدام نفس الأمر: version: set. العملية هي عملية لمرة واحدة ، لأننا لم نعد نخزن نسخة المشروع في ملف.

نتيجة للتغييرات ، يمكنك إزالة تكوين maven-release-plugin و scm block من ملف pom.

»من السلبيات:
إذا كنت تستخدم إصدارات SNAPSHOT في مكان ما ، فقد يبدأ الارتباك ، والآن تبدو جميع إصدارات SNAPSHOT متشابهة. وربما هذه الطريقة لإطلاق المشاريع ليست لك.

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

»من المحترفين:

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

لذلك ، أنقذ خطان العالم مرة أخرى.
هذا كل شيء ، شكرا لكم على اهتمامكم!

Source: https://habr.com/ru/post/ar424425/


All Articles