Как часто вы обновляете драгоценные камни в неизданном проекте?

Question

У меня есть несколько побочных проектов, которые либо находятся в разработке, либо предназначены для друзей и семьи.Исключение ( modulecounts.com ) довольно тривиально.

На работе в более крупной организации кажется, что мы всегда создаем правила, запрещающие слишком частое обновление гемов.Это становится историей, запланированной на определенный спринт.Он должен быть скоординирован с Ops, чтобы убедиться, что они будут готовы к обновлению производственной среды и т. Д.

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

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

Что делатьты сделаешь?Что за счастливая среда?

Answer 1

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

1. Понимайте, какую более новую версию вы используете. Читайте заметки о выпуске. Если вы используете хорошо документированные драгоценные камни, вы сможете узнать, что нового в этой версии драгоценного камня, и собираетесь ли вы иметь дело с амортизацией.
2. Используйте версии Gem в вашем Gemfile. Мой любимый оператор ~>. ~> 2.1 означает> = 2.1, но <2.2, это означает, что вы можете гарантировать, что ваши драгоценные камни остаются в актуальном состоянии, не беспокоясь об устаревших, потому что вы можете оставаться в пределах определенных версий драгоценных камней. Это часто означает, что вы будете продолжать получать обновления безопасности для конкретной версии гема, сохраняя те же форматы команд и функций. </li>
3. Не обновляйте сразу на критических проектах. Лучше немного подождать, когда выйдут новые версии гемов, прежде чем обновляться. Протестируйте новую версию gem в вашей ветке разработки или подождите, чтобы увидеть, найдут ли другие ошибки. Будьте в курсе прогресса новой версии драгоценного камня.
4. Пишем тесты. Не тестируйте гемы напрямую, но убедитесь, что ваш код, который зависит от гемов, работает так, как вы ожидаете. Чем больше охвата вы сможете получить, особенно для критически важных функций, тем легче будет определить, работает ли новая версия гема.
5. Протестируйте свое приложение после обновления гема. Часто приятно создать новую ветку git и обновить гем в этой ветке, чтобы обеспечить работоспособность вашего кода. Вы можете даже поддерживать ветвь для нескольких циклов разработки или спринтов, пока она тестируется или обновляется ваш код, только сливая его обратно в основную ветку, только когда вы уверены, что обновление gem было хорошим выбором.

Я предпочитаю оставаться в курсе самых последних изменений в драгоценных камнях, стараясь не мешать моему развитию постоянно обновляться. Я пытаюсь выполнить обновление по расписанию, которое работает для моей команды, например, каждые две недели, при этом следя за обновлениями безопасности. Это также помогает автоматически настроить производственную среду. Bundler отлично подходит для этого, потому что ваш Gemfile.lock может гарантировать, что ваша производственная среда использует те же гемы, что и ваша среда разработки.

Answer 2

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

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

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

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