Оволодіння оновленнями Rails: Покроковий посібник для безшовних оновлень

У моїй попередній компанії я мав можливість оновити наше застосування з Rails 5.2.8 до 6.1. Спочатку я був трохи нервовий через свій обмежений досвід оновлень технологій. Однак, дотримуючись кроків, описаних нижче, я успішно завершив оновлення без жодного простою в продуктивному середовищі. Давайте розглянемо процес і виділимо помилки, яких варто уникати.

Що потрібно перевірити перед початком оновлення Rails

1. Покриття тестами
   Переконайтеся, що ваше застосування має надійне покриття тестами. Надійні тести допоможуть виявити регресії та перевірити функціональність під час процесу оновлення.
2. Залежності від гемів
   Перевірте всі залежності від гемів і переконайтеся, що вони сумісні з цільовою версією Rails. Шукайте оновлення або альтернативи для гемів, які більше не підтримуються.
3. Код з monkey patching
   Ідентифікуйте будь-який код з monkey patching в вашому застосуванні. Ці спеціальні переоприділення можуть не працювати або поводитися непередбачувано з новою версією Rails, тому їм потрібно приділити особливу увагу.
   4.
4. Зміни в рамках фреймворку
   Перегляньте журнал змін Rails та релізні нотатки для версій, через які ви оновлюєте. Ознайомтесь з основними змінами, застарілими функціями та поламаними оновленнями, які можуть вплинути на ваше застосування.
5. За замовчуванням конфігурація
   Порівняйте конфігураційні файли вашого застосування з конфігурацією за замовчуванням для цільової версії Rails і шукайте зміни, які можуть вплинути на поточний код.
6. Налаштуйте середовище для віддзеркалення продуктивного
   Перед початком процесу оновлення важливо налаштувати середовище для тестування, яке максимально схоже на ваше продуктивне середовище.
   Це гарантує, що будь-які проблеми, які виникли під час оновлення, можна буде виявити та вирішити до того, як вони вплинуть на користувачів, тобто: порівняти конфігурації, інтеграції з третіми сторонами, використовувати продуктивну базу даних, щоб уникнути проблем з даними.

Почнемо оновлення (це буде справжня американські гірки)

Ми використали техніку подвійного завантаження, щоб спростити процес оновлення. Такий підхід дозволив нам уникнути повного вимкнення застосунку у разі невдачі та усунув труднощі з управлінням великими запитами на злиття.
Це також зменшило необхідність частих оновлень гілки оновлення, заощаджуючи час на вирішення конфліктів з основною гілкою.

Використали гем next_rails для налаштування подвійного завантаження, ось тут детальні інструкції, як налаштувати.

next_rails також надає звіт про застарілі геми, що допоможе дізнатися, які геми не сумісні з цільовою версією.

bundle exec bundle_report compatibility --rails-version=6.1

Оновіть версію Rails у Gemfile, як показано нижче, і ви готові до роботи.

def next?  
  File.basename(__FILE__) == "Gemfile.next"  
end  

source 'https://rubygems.org'  
if next?  
  gem 'rails', '~> 6.1.6'  
else  
  gem 'rails', '~> 5.2.8'  
end

Кроки, які були виконані для оновлення

1. Оновили всі залежності гемів до версій, сумісних з цільовою версією Rails.
   2.
2. Змінено application.rb, щоб використовувати умовну логіку (if-else), яка завантажує конфігурацію за замовчуванням для цільової версії Rails разом з поточною версією.
3. Виконано набір тестів і задокументовано всі неуспішні тести у файлі failures.txt для систематичного налагодження.
4. Розроблено скрипт, який обробляє файл failures.txt та генерує масив, що містить: Тип помилки, Назву файлу, що містить неуспішний тест, Конкретний неуспішний тест.
5. Налаштовано додаткову GitHub pipeline для виконання тестів на цільовій версії Rails, виключаючи поточні неуспішні тести, зазначені у файлі failures.txt.
6. Поступово усували типи помилок, видаляючи виправлені тести зі списку виключених тестів у RSpec.
7. Коли всі тести були виправлені, змінили зміни в основну гілку для стабілізації застосунку.
8. Створено нову гілку для завершення оновлення, зробивши цільову версію Rails за замовчуванням та видаливши будь-які посилання на попередню версію.
   8.
   Проведено ретельне смок-тестування фінальної гілки, щоб забезпечити функціональність і стабільність застосунку після оновлення.

Помилки, які ми зробили

1. Не налаштували Sentry на staging середовищі
   Після розгортання в продукції ми стикнулися з численними помилками в Sentry, пов'язаними з breadcrumb в гемі sentry-ruby та проблемами з гемом BigDecimal. Ці проблеми могли бути уникнуті, якби наше staging середовище було налаштовано як точна репліка продукційного середовища.
2. Неправильна інтеграція API на staging середовищі
   Наше staging середовище не мало належної конфігурації для інтеграцій API, що призвело до проблем, які проявились лише в продукції.

Як ми покращили ситуацію

У наступній спробі релізу ми налаштували Sentry на staging середовищі та забезпечили, щоб інтеграції API відтворювали продукційне середовище.
Це дозволило нам виявити та вирішити ці проблеми до розгортання, забезпечивши більш плавний процес випуску.

Посилання — https://www.fastruby.io/blog/next-rails-gem.html

Перекладено з: Mastering Rails Upgrades: A Step-by-Step Guide for Seamless Upgrades