Каковы первые шаги по упрочению устаревшего приложения Rails?

Question

Существует система производства, которая работает в течение многих лет, сначала как приложение PHP, а затем как гибрид с Rails, а теперь полностью в Rails. Неясно, как долго это было вокруг. Самый старый git совершает 5 лет назад.

Целью является обеспечение бесперебойной работы системы. Неважно, какой код мы используем, пока ничего не сломается. В настоящее время он находится в версии Rails 3.2.33.

Если мы не обновляем какие-либо драгоценные камни, у нас появляется шанс стать устаревшим и неиспользуемым. Если мы обновим, нам нужно будет внести изменения в код, из-за чего могут возникнуть потенциальные ошибки. Мы не только сталкиваемся с гнилом кода, но и простоем из-за сбоев AWS.

Что было бы первым шагом, чтобы убедиться, что ничего не сломалось? Я провел месяцы, написав тесты на огурцы (интеграция), но трудно покрыть каждый край. Приложение работает так долго, что исправлено большинство ошибок, и есть несколько новых исключений. Тестирование не было приоритетом с самого начала, поэтому большая часть кода недокументирована.

Answer 1

Честно говоря, я считаю, что Ruby on Rails не идеально подходит для такого рода приложений. И Ruby, и Rails имеют очень агрессивное расписание релизов, и Rails особенно не боится отката назад совместимости. Rails отлично подходит для гибкого развития, где вещи всегда меняются, но ценой долговременной стабильности.

Я предполагаю, что ваше приложение достаточно велико, чтобы вы не хотели переключаться ни на что другое. Например, Sinatra не сильно изменился и был бы более стабильным вариантом.

Если вы придерживаетесь Rails, я бы рекомендовал избавиться от как можно большего количества зависимостей от драгоценных камней. Всегда существует опасность, что они больше не будут развиваться или что они могут ввести ошибки или уязвимости.

Кроме того, насколько это возможно, рекомендуется использовать POROs (простые старые объекты Ruby) над кодом, зависящим от Rails. Обычно требуется больше работы, но вы получаете более стабильный и многоразовый код.

Я понимаю, что может быть больше работы, чем вы хотите применить в таком приложении, но это мой лучший совет.

Answer 2

Первым шагом было бы поставить конкретную версию gem для всех драгоценных камней, используемых в файле gem.

Для exmaple

gem 'rspec-rails' 

может стать

gem 'rspec-rails', '2.14.1' 

Вы можете выяснить, какие версии в настоящее время используются, глядя на ваш Gemfile.lock, например, эта линия в Gemfile.lock шоу версия, выбранная для rspec:

rspec (2.14.1) 

и даже если Gemfile не имеет версии n, например.

gem chronic 

Gemfile будет уже версия используется, например,

chronic (0.10.2) 

Если мы не обновить все драгоценные камни, мы запустим шанс стать устаревшим и undeployable.Если мы обновим, нам нужно будет внести изменения в код, в результате чего потенциальные ошибки будут ползать.

Да, это ваша дилемма. Магии нет, вам нужно выбрать, какой из этих двух приоритетов вы хотите решить. Как указывает aNoble, RoR не является основой, которая может «оставаться на месте». постоянное изменение драгоценных камней, которые объединяются в большинство приложений, означает, что приложения RoR не выдерживают достаточного старения.

Вы должны объяснить и повторить, повторить, повторить это для владельца проекта. Часто это тот принцип, который «принят» - но не совсем - по мере того как одни и те же вопросы продолжают задаваться «несмотря на это, как я могу его обновить, как я могу убедиться, что ничего не меняется или не ломается и т. Д.»

Если заявка будет удалена через пару месяцев, никаких проблем. Если нет реального плана заката приложения, и он будет продолжать оставаться важной частью бизнеса, тогда вам просто нужно использовать ресурсы для его поддержания. нет бесплатного обеда на территории RoR.

Answer 3

Написание многих тестов является ключевым первым шагом, рад это видеть. Проверьте информацию о своем заявлении, чтобы узнать, не хватает ли вы тестов важных областей кода и убедитесь, что у вас есть интеграционные тесты, которые охватывают ключевые последовательности. Идея состоит в том, чтобы изменить ваши тесты, чтобы уменьшить риск того, что изменение приведет к сбою, видимому пользователю.

Теперь настройте непрерывное тестирование на какой-либо системе.

Установите Gemfile и .ruby-версию, чтобы у вас был конкретный контроль над тем, какие версии всего загружаются. Это не автоматически обновляется, но гарантирует, что у вас есть управление над тем, что вы обновляете. Проверьте как Gemfile, так и Gemfile.lock.

На этом этапе вы можете медленно увеличить номера версий. Не перескакивайте множество номеров версий - обычно лучше обновляться медленно, чтобы вы могли видеть предупреждения об устаревании. Исправьте их, промойте, повторите.

Измените свои валидаторы (ввод), чтобы быть разборчивыми белыми списками («он должен быть такой формы, или я не буду его принимать»). Если вы можете предотвратить попадание плохих данных с в систему, это скорее работает правильно и, как правило, будет сложнее атаковать.

Для обеспечения безопасности рассмотрите возможность добавления безопасных головок и установите CSP так сильно, как вы можете стоять.

Начать добавление некоторых статических анализаторов. Rubocop и Brakeman очень полезны. Вероятно, вам придется настроить Rubocop только для того, чтобы жаловаться на некоторые вещи, а затем медленно увеличивать то, что они сообщают. Добавьте все свои проверки к команде «rake» по умолчанию, чтобы вы могли просто набрать «rake» для запуска статических анализаторов и набора тестов.

Нет никакой магии, независимо от того, какую структуру вы используете. Люди ошибаются, и притворяясь, что это иначе, не полезно.

Вы можете использовать CII Best Practices badge project. Он использует RoR, и я это делаю. В частности, см: * CONTRIBUTING * Security information (assurance case)

От ВОЙСКА: «В целом мы стараемся быть активными для обнаружения и устранения ошибок и уязвимостей, как только возможно, и уменьшить их влияние, когда они случаются и мы. используйте защитный дизайн и стиль кодирования, чтобы уменьшить вероятность ошибок, множество инструментов, которые пытаются обнаружить ошибки на ранней стадии, и автоматический набор тестов со значительным охватом.«