درباره ما
در 1C ما نه تنها یک پلت فرم را توسعه می دهیم
ورود
ما اغلب از maven به عنوان یک سیستم ساخت برای برنامه های جاوا استفاده می کنیم و در این مقاله کوتاه می خواهیم در مورد یکی از مشکلاتی که در فرآیند سازماندهی توسعه با آن مواجه بودیم و رویکردی که به ما اجازه می دهد بر این مشکل غلبه کنیم صحبت کنیم. مسئله.
پیش نیازها و گردش کار
با توجه به ویژگیهای توسعه در پروژههای ماون، ما از ماژولها، وابستگیها و پروژههای فرزند زیادی استفاده میکنیم. تعداد فایل های pom در یک درخت می تواند ده ها یا حتی صدها باشد.
به نظر می رسد: چیز مهمی نیست، آنها یک بار آن را ایجاد کردند و آن را فراموش کردند. اگر نیاز به تغییر یا اضافه کردن چیزی در همه فایل ها به طور همزمان دارید، ابزارهای مناسب زیادی در ویرایشگرها و IDE ها وجود دارد. رایج ترین تغییر منظم به pom.xml چیست؟ ما معتقدیم که تغییرات در نسخه های پروژه و وابستگی ها. شاید کسی بخواهد با این بحث کند، اما این دقیقاً وضعیت در مورد ماست. دلیل آن در این واقعیت نهفته است که، همراه با هسته، به طور همزمان بسیاری از کتابخانههای خود را توسعه میدهیم، و برای تکرارپذیری مداوم نتایج ساخت و آزمایش، استفاده از عکسهای فوری به نظر ما رویکرد مناسبی نیست. به همین دلیل لازم است با هر بیلد شماره نسخه را در پروژه ها افزایش دهید.
همچنین، هر از چند گاهی، یک توسعهدهنده نیاز دارد تا شاخهای از کتابخانه خود را بسازد و عملکرد آن را در برابر همه وابستگیها بررسی کند، که برای این کار باید نسخه همه آنها را به صورت دستی تغییر دهد.
راه حل اولیه
با چنین تغییرات مکرر و متعدد نسخه، من می خواهم فرآیند را در CI ساده و خودکار کنم. اینجاست که یک پلاگین راحت و شناخته شده به کمک می آید. نسخه-maven-پلاگین - آن را وصل کرده و راه اندازی کنید
mvn -N versions:set -DnewVersion=2.0.1
و Maven همه چیز را همانطور که باید انجام می دهد: از طریق سلسله مراتب از بالا به پایین اجرا می شود و همه نسخه ها را جایگزین می کند - زیبایی! اکنون تنها چیزی که باقی مانده است این است که یک درخواست کشش مطرح کنید، همکاران تغییرات را بررسی خواهند کرد و شما می توانید به سرعت به صندوق عقب بپیوندید. به سرعت؟ مهم نیست چگونه باشد. یکی دو صد pom.xml برای بررسی، و این کد به حساب نمی آید. علاوه بر این، هیچ کس از تداخل ادغام با این تعداد فایل تغییر یافته در امان نیست. در اینجا لازم به ذکر است که در فرآیند CI، تغییرات نسخه به طور خودکار همراه با تغییرات در عملکرد رخ می دهد و نه به نحوی جداگانه.
ویژگی های جدید
مدتی آرام شدیم و با استعفای خودمان، تا زمانی که بچه ها از آنجا بودند، همینطور زندگی کردیم
بسته تمیز mvn -Drevision=2.0.0
مقادیر ویژگی های سیستم بر مقادیر تعریف شده در اولویت هستنداملاک>.
والدین
4.0.0
org.apache
آپاچی
18
org.apache.maven.ci
ci-parent
اولین CI Friendly
${revision}${sha1}${changelist}
...
1.3.1
-عکس فوری
نسل
4.0.0
org.apache.maven.ci
ci-parent
${revision}${sha1}${changelist}
org.apache.maven.ci
سی-کودک
...
اگر می خواهید نسخه 2.0.0-SNAPSHOT را بسازید، فقط از آن استفاده کنید
بسته تمیز mvn -Drevision=2.0.0
اگر میخواهید یک نسخه منتشر کنید، فقط SNAPSHOT را بازنشانی کنید
mvn -Dchangelist= بسته تمیز
*نمونه های بالا برگرفته از
واقعیت تلخ
همه چیز خوب و سالم است، وقت آن است که احساس رضایت کنید، اما نه. به نظر می رسد که این روش برای نصب و استقرار کار نخواهد کرد، زیرا در توضیحات مصنوعات منتشر شده در مخزن جایگزین نمی شود. ${بازبینی} به معنای آن است و ماون دیگر متوجه نخواهد شد که در مورد چیست.
org.apache
آپاچی
${بازبینی}
نوری در انتهای یک تونل
ما باید به دنبال راه حلی برای مشکل باشیم. می توانست وضعیت را نجات دهد
افزودن افزونه به پروژه
org.codehaus.mojo
flatten-maven-plugin
1.1.0
درست است، واقعی
solveCiFriendliesOnly
صاف کردن
فرآیند-منابع
صاف کردن
صاف کردن.تمیز کردن
تمیز
تمیز
انجام شده است
پایان خوش
از این به بعد، برای اینکه نسخه کل پروژه را تغییر دهیم و همه وابستگی ها از آن مطلع شوند، فقط باید عنصر را ویرایش کنیم.تجدید نظر> فقط در ریشه pom.xml. صد و دو تا از این فایل ها با همین تغییر به بررسی نمی رسند، بلکه یکی. خب نیازی به استفاده نیست نسخه-maven-پلاگین.
منبع: www.habr.com