ارتقاء برنامه های Ruby on Rails

هر سال، ما بخشی از زمان خود را صرف ارتقای برنامه های Ruby on Rails می کنیم. برخی از آنها توسط ما ایجاد شده اند (و بنابراین ما همه چیز را در مورد آنها می دانیم) و برخی از آنها نه. در هر صورت با وجود تفاوت آنها (وابستگی ها، نسخه ها و …) رویکرد یکسانی داریم.

چرا باید برنامه های Ruby on Rails را ارتقا دهیم؟
Rails چارچوبی است که بسیار سریع حرکت می کند. پس از Semantic Versioning، تیم هسته Rails به طور متوسط ​​هر 3 سال یک نسخه اصلی، به طور متوسط ​​هر سال یک نسخه کوچک را به روز می کند و سالانه حدود 12 نسخه رفع اشکال را منتشر می کند. با هر نسخه اصلی از چارچوب، قدیمی ترین نسخه اصلی فریم ورک به EOL (پایان زندگی) خود می رسد. برای مثال، زمانی که Rails 7 منتشر شد، Rails 5 به EOL خود رسید. این بدان معناست که هیچ به‌روزرسانی‌هایی را که نسخه‌های جدیدتر دریافت خواهند کرد (در این مورد Rails 6 و Rails 7) دریافت نخواهد کرد. بنابراین داشتن نسخه قدیمی Rails به این معنی است که برنامه شما وصله هایی برای مسائل امنیتی و امنیتی شدید (طبق خط مشی تعمیر و نگهداری) دریافت نمی کند و ممکن است در برابر مهاجمان آسیب پذیر باشد. همچنین، ارتقا ندادن Rails اغلب به این معنی است که در نهایت ارتقاء Rails در آینده دشوارتر خواهد بود.

در عین حال، نسخه های Ruby on Rails از نسخه های روبی خاصی پشتیبانی می کنند. به عنوان مثال، اگر می خواهید برنامه Rails 5 خود را به Rails 6 ارتقا دهید و در حال حاضر روی Ruby 2.3 در حال اجرا هستید، باید حداقل به Ruby 2.5 ارتقا دهید (طبق این جدول). اما به این سادگی نیست. Ruby چرخه انتشار خود را دارد و نسخه های مختلف آنها EOL خاص خود را دارند. در این مورد، Ruby 2.5 قبلاً به EOL خود رسیده است (به شاخه های روبی مراجعه کنید)، بنابراین توصیه می شود به نسخه جدیدتر ارتقا دهید.

ارزیابی
اولین مرحله ارتقاء، جمع آوری اطلاعات است. جستجو در برنامه برای پاسخ به سوالات زیر:

نسخه فعلی روبی چیست؟
نسخه فعلی Ruby on Rails چیست؟
نسخه مورد نظر Ruby on Rails چیست؟ یعنی به چه نسخه ای می خواهیم ارتقا دهیم؟ در هر صورت توصیه می شود نسخه ریل را در مراحل کودکی یعنی در تغییرات کوچک ارتقا دهید. از Rails 5.0.x به Rails 5.1.x، سپس به Rails 6.0.x، سپس 6.1.x و غیره و نه مستقیماً از Rails 5.0.x به 6.1.x.
برنامه کجا اجرا می شود؟ این سوال بسیار مهم است زیرا فروشندگان مختلف ممکن است از نسخه های مختلف Ruby پشتیبانی کنند. یا حتی می‌تواند فلز خالی باشد، در این صورت ممکن است کنترل بیشتری روی نرم‌افزاری که نصب می‌کنیم داشته باشیم (اما ممکن است مشکلات دیگری داشته باشیم).
آیا از پایگاه داده استفاده می کنیم؟ اگر چنین است، کدام یک؟ کدام نسخه؟ گاهی اوقات ارتقاء به نسخه DB نیز لازم است، چه برای امنیت و/یا ویژگی های جدید مورد نیاز برای نسخه های جدیدتر Rails یا یک وابستگی. برای مثال، Rails 6 پشتیبانی از PostgreSQL < 9.3 را در سال 2018 قطع کرد. این ارتقاء DB ممکن است با انتقال داده نیز همراه باشد.
آیا برنامه تست دارد؟ انجام تست‌ها یک مزیت عالی است زیرا به ما امکان می‌دهد به سرعت تشخیص دهیم که آیا ارتقا چیزی را خراب نکرده است. با این حال، این بدان معنا نیست که شکسته نمی شود.
پاسخ به این سؤالات به ما کمک می کند تا بفهمیم آخرین نسخه هایی که می توانیم مفسر، چارچوب و وابستگی ها را ارتقا دهیم کدامند. توجه به این نکته بسیار مهم است که زیرساختی که برنامه در آن اجرا می شود آخرین نسخه هایی را که می توانیم به آن ارتقا دهیم تعیین می کند. یعنی این مانند استقرار یک کانتینر، یک برنامه Heroku، یک برنامه AWS Elastic Beanstalk یا هر راه‌اندازی خاص فروشنده نیست.

ارتقا دهید
پس از جمع‌آوری این اطلاعات، سعی می‌کنیم مفسر، چارچوب و وابستگی‌ها را به آخرین نسخه‌های ممکن ارتقا دهیم، بدون اینکه عملکرد برنامه به خطر بیفتد (باز هم، آزمایش‌ها یک امتیاز عالی هستند). ما این کار را با ارتقاء یک نسخه Rails در یک زمان انجام خواهیم داد. روند کمی برای آن وجود دارد:

نسخه Rails را ارتقا دهید.
نسخه روبی را به حداکثر ممکن به نسخه Rails که در حال ارتقاء آن هستیم ارتقا دهید.
ارتقاء وابستگی ها (در صورت نیاز و امکان). این یکی از دردناک ترین مراحل است و می تواند کار را سخت کند. برخی از پروژه‌ها از وابستگی‌هایی استفاده می‌کنند که دیگر تا یک نسخه Ruby/Rails حفظ یا نگهداری نمی‌شوند و گذشته از آن نسخه، امکان ارتقا وجود ندارد. ممکن است لازم باشد جایگزین هایی برای این وابستگی ها پیدا کنیم، که در بیشتر موارد نیاز به کار اضافی دارد.
تست ها را اجرا کنید (در صورت وجود) و بررسی کنید که همه چیز همانطور که انتظار می رود کار می کند. اگر برنامه آزمایشی ندارد، یا حتی اگر آزمایشی دارد، توصیه می‌شود حداقل به صورت دستی بررسی کنید که مسیرهای حیاتی همچنان مطابق انتظار کار می‌کنند. گاهی اوقات، تغییرات کوچکی در روش‌ها (از Rails یا وابستگی) ایجاد می‌شود که نتایج مثبت کاذب می‌دهد. مهم است که این مسیرهای حیاتی را به صورت دستی بررسی کنید تا هیچ چیز مهمی خراب نشود.
برنامه ارتقا یافته را در یک محیط جدید مستقر کنید.
این مراحل باید به تعداد نسخه‌های Rails که نیاز به ارتقا داریم تکرار شوند.

در حالی که بیشتر ارتقاها برای یک محیط محلی یکسان هستند، آنها در بخش کلیدی معماری متفاوت هستند: زیرساخت. این مانند استقرار یک برنامه ریل برای فلز لخت نیست که باید همه چیز را (کاربران سیستم عامل، سرور وب، سرور برنامه، سرور پایگاه داده، مفسر و غیره) و مقیاس دستی فراهم کند، و در پلتفرمی مانند AWS Elastic Beanstalk، Heroku استقرار کنید. یا سایر فروشندگان که تامین و مقیاس بندی توسط پلتفرم انجام می شود.

به روز رسانی برنامه هایی که روی فلز خالی اجرا می شوند
به روز رسانی برنامه هایی که روی فلز خالی اجرا می شوند معمولاً کمی بیشتر طول می کشد زیرا ایجاد یک محیط جدید ممکن است شامل تهیه دستی باشد. حتی تلاش و توصیف نحوه انجام آن بسیار دشوار است زیرا برنامه‌هایی که روی فلز خالی اجرا می‌شوند دارای تنظیمات زیادی هستند که می‌توان تصور کرد، بنابراین این به خوانندگان بستگی دارد که بفهمند چگونه زیرساخت برنامه خود را ارتقا دهند.

ارتقاء برنامه های AWS Elastic Beanstalk
AWS Elastic Beanstalk با یک محدودیت همراه است: AWS Elastic Beanstalk for Ruby در حال حاضر از دو نسخه Ruby پشتیبانی می کند: Ruby 2.7 و Ruby 3.0. بنابراین، اینها حداکثر نسخه های یاقوتی هستند که می توانید آرزو کنید. توصیه می شود به آخرین مورد ارتقا دهید.

به طور معمول، اگر از Elastic Beanstalk برای برنامه خود استفاده می کنید، برنامه خود را اغلب ارتقا می دهید زیرا فقط از دو نسخه از مفسر پشتیبانی می کند. چنین ارتقاءهایی عمدتاً شامل ارتقاء پلتفرمی است که برنامه روی آن اجرا می شود. به عنوان بخشی از ارتقاء، ما به یک محیط متفاوت نیاز خواهیم داشت. در حالت ایده آل، یک محیط مرحله بندی با استفاده از پایگاه داده مشابه با پایگاه داده مرحله بندی فعلی.

ارتقاء برنامه های Heroku
ارتقاء یک برنامه Heroku احتمالاً ساده‌ترین نمونه از این نمونه‌ها است زیرا به هیچ اقدام دیگری به جز ارتقاء کد نیاز ندارد. Heroku هوشمند است و دقیقاً می داند که شما به چه نسخه ای از Ruby ارتقا می دهید (با خواندن فایل .ruby-version).

نتیجه
نتیجه یک ارتقا معمولاً یک شاخه git حاوی ارتقاء و یک محیط جدید حاوی چنین شاخه ای است که آماده ادغام است.

منتظر پست‌های بعدی این مجموعه باشید که در آن درباره فرآیندها و اقداماتی برای کمک به کوچک‌تر کردن، دردناک‌تر کردن و کاهش خطرات ارتقاءها صحبت خواهیم کرد.