В разработке программного обеспечения есть несколько аксиом:

Разработчики любят блестящие новинки.

Это просто наша природа.

Разработчики тоже ленивы, особенно когда дело касается обыденных и скучных задач.

Это также просто наша природа.

Задний план

Здесь, в LoadUp, мы стараемся быть как можно ближе к передовым технологиям, оставаясь при этом достаточно далеко от них, чтобы не попасть в Альфа-каньон адских ошибок компиляции.

Фактически, мы держимся так близко к пределу возможностей, что наши рабочие приложения обычно работают на последних языковых версиях в течение нескольких часов после их выпуска.
У нас даже есть бета-версии (в настоящее время Ruby 2.7 и Rails 6 альфа-версии!), работающие локально. , ожидая, пока наши поставщики CI обновят свои образы.

Возможно, вы спросите: «Как вам удается так близко работать без каких-либо перебоев в работе или новых ошибок, а также при этом поддерживать здравомыслие и здоровье разработчиков?»

Наш ответ состоит из трех частей:

1. Надежный набор тестов,
2. Автоматические перехватчики git и
3. Автоматизированный менеджер зависимостей.

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

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

Проблема

Часто в программных проектах и ​​командах обновление зависимостей рассматривается как «рутинная работа». Это не способствует развитию продукта, и обновление вашего кода для обеспечения совместимости часто может оказаться кошмаром. В некоторых трекерах проблем даже есть специальный тип задач для работы по дому со скучным значком серого круга, который выглядит не так весело, как зеленый значок функции или фиолетовая молния эпиков!

Теперь, помимо программного обеспечения, когда вы слышите слово «рутинная работа», что приходит вам на ум?

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

Будучи ленивым ребенком, я часто избегал этих дел, пока не случалось одно из двух:

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

Мы все были в ситуациях и организациях, где обновление зависимостей было проблемой «низкого» приоритета. Старая пословица «Если это не сломано, не чини это» звучит в этих случаях несколько верно.

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

Если зависимости игнорируются достаточно долго, часто из-за принципа программное обеспечение никогда не умирает, команды могут оказаться в серьезных дырах, из которых очень сложно выбраться. Сам Github, как известно, когда-то имел две основные версии и почти на десять лет отставал от старой вилки Rails! (примечание — это выступление Эйлин Учителл, подытоживающее их возвращение к мастеру Rails, увлекательно.)

Отставание от ваших зависимостей вызывает проблемы во многих областях:

1. Вы уязвимы для атак на систему безопасности, которые могли быть запатчены
2. Документация и учебные пособия становятся ужасно бесполезными, поскольку они обычно нацелены на более свежие версии библиотеки
3. Вы начнете терять инженерные таланты, которые (как упоминалось выше…) хочет работать с _новыми, блестящими вещами_
4. Ваше приложение может начать застаиваться и чувствовать себя «старым»!

Что, если бы был лучший способ?

Войдите в Dependabot.

Решение

Dependabot, согласно их веб-сайту, «создает запросы на извлечение, чтобы обеспечить безопасность и актуальность ваших зависимостей».

Поскольку целью Microsoft является *захват мира*, недавно было объявлено, что Dependabot был приобретен Github.

Dependabot будет регулярно сканировать зависимости вашего репозитория (каждый день, неделю, месяц, решать вам!), и когда он находит устаревшую зависимость, он выдает простой PR против вашего репозитория с запросом на обновление до этой зависимости. Поскольку он выдает PR, если у вас настроена непрерывная интеграция, он будет запускать ваш пакет CI, анализировать и тестировать ваше приложение с новой версией этой зависимости (Sweet!).

Самое приятное, что это БЕСПЛАТНО!

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

Это то, что мы в бизнесе называем Win-Win.

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

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

Реализация

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

Настройка репозитория

Прежде всего, найдите репозиторий с зависимостями. (т.е. имеет Gemfile, package.json и т. д.). Если у вас его нет, вы можете просто создать его из командной строки следующим образом:

npx create-react-app dependabot-example
cd dependabot-example
hub create -p
hub push — set-upstream origin master

Поскольку `create-react-app` довольно точно обновляется, но не совсем, это хороший репозиторий для использования в качестве примера.

Зарегистрироваться

Затем перейдите к Dependabot и нажмите кнопку «Войти».

Это перенаправит вас на вход в Github через OAuth.

Довольно просто, а?

Ссылка на репозиторий

Теперь вернитесь на панель управления Dependabot, щелкните ссылку «Добавить репозитории» в правом верхнем углу и разрешите Dependabot доступ к только что созданному репозиторию (или к вашему собственному, не имеет значения!)

Теперь снова вернитесь на панель инструментов, еще раз нажмите «Добавить репозитории» и настройте репозиторий для получения PR:

Как только вы нажмете «Добавить выбранное», все готово! Ваш репозиторий почти сразу начнет получать PR для устаревших пакетов.

Расширенная конфигурация

Конфигурация Dependabot по умолчанию будет сканировать ваш репозиторий один раз в день и выдавать PR. Для большинства проектов это разумная конфигурация. Для более крупных проектов или проектов с зависимостями, которые могут часто обновляться, это может стать громоздким в управлении. В LoadUp мы настроили несколько наших репозиториев для получения обновлений раз в неделю по воскресеньям, и это простая задача — просмотреть PR и объединить их, чтобы быстро и легко выиграть в понедельник утром.

Для некоторых приложений (таких как Rails 5.2+) необходимо управлять несколькими наборами зависимостей. Вы можете настроить Dependabot для сканирования любого количества источников репозитория, включая смешение языков (Gemfileи package.json) и даже вложенных проектов в монорепозиторий! В LoadUp наши интерфейсные приложения вложены в наш основной монорепозиторий Rails с использованием `create-react-app`, что упрощает тестирование полного стека, поэтому у нас есть основное репозиторий, настроенное для сканирования как корневого Gemfile, так и package.json, а также package.json во вложенных папках внешнего интерфейса.

В LoadUp мы используем рабочий процесс git на основе магистрали, что означает, что все PR объединяются непосредственно в master, но некоторым организациям нравится использовать подход git-flow с master и отдельной ветвью development, когда PR объединяются в development, а затем фрагменты объединяются из development. в master и помечены все сразу. Dependabot позволяет вам настроить ветку, на которую вы хотите нацелить PR, поэтому git-flow полностью поддерживается!

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

Кроме того, если вы хотите, чтобы ваши зависимости оставались заблокированными, но вы хотите, чтобы _их_ зависимости обновлялись, вы также можете настроить это, выбрав «Только обновления файла блокировки».

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

Вывод

Dependabot позволил нам в LoadUp быть значительно более уверенными в том, что наши приложения всегда обновлены благодаря исправлениям ошибок безопасности, новым интересным функциям из пакетов и не дают нашим родителям кричать на нас, чтобы мы выполняли нашу работу по дому. Это упростило управление зависимостями, и теперь, поскольку оно бесплатное, добавить его в свои проекты не составит труда.