Примените автоматизированное управление зависимостями в своей команде
В этой статье мы рассмотрим, что такое программные зависимости и как ими можно управлять в архитектуре микросервисов. Затем мы рассмотрим некоторые риски и рекомендации, которым следует следовать при работе с управлением зависимостями.
📝 В этой статье я буду использовать термин "пакет" для обозначения фрагмента кода, но вместо пакета можно использовать и другие термины (например, библиотека).
Начнем с определения того, что такое зависимость и какие типы зависимостей существуют.
Зависимость может быть внешним пакетом, который сам может иметь ноль или несколько зависимостей. После включения в проект он становится зависимым от этого проекта. То же самое происходит со всеми его зависимостями.
Давайте рассмотрим пример в микросервисной архитектуре, который представляет собой интернет-магазин. В процессе покупки заказа системе необходимо обработать платеж. Для этой цели пакет платежного шлюза включен в качестве внешней зависимости.
Когда пакет платежного шлюза добавляется в проект, он называется прямой зависимостью. Если у него есть зависимости, связанные с другими пакетами, эти зависимости называются транзитивными зависимостями.
Теперь, когда мы знаем основы о зависимостях и их типах, давайте посмотрим, как ими управлять.
Управление зависимостями
Теперь представьте, что количество микросервисов в приведенном выше примере начинает расти, и команда разработчиков создает отдельный репозиторий кода для каждого микросервиса. Количество прямых и транзитивных зависимостей станет неуправляемым для команды вручную.
Одним из возможных решений является использование бесплатного инструмента, такого как Whitesource Renovate, который автоматически сканирует зависимости, снимая эту нагрузку с команды разработчиков. Таким образом, можно обнаружить уязвимые версии зависимостей и обновить их до самых последних.
Каждый раз, когда зависимости требуется обновление, Renovate делает две вещи: создает новую ветку и открывает pull request с изменениями в новой ветке.
Таким образом, он уведомляет команду разработчиков о том, что был создан новый запрос на вытягивание, и члены команды могут решить, хотят ли они исправить зависимость путем слияния запроса на вытягивание или нет.
По мере роста проекта Renovate будет:
- Непрерывный поиск уязвимых зависимостей.
- Включите журналы изменений и историю коммитов изменений зависимостей в основной ветке.
- Запускайте тесты при каждом обновлении, чтобы избежать регрессионных ошибок.
Он также имеет панель управления зависимостями, которая показывает обзор состояния зависимостей репозиториев, позволяя команде отслеживать и управлять зависимостями проекта.
Давайте посмотрим, что может пойти не так, если не настроить правильный процесс управления зависимостями.
Риски наличия уязвимых зависимостей
Когда проект начинает расти, количество зависимостей также растет, как и риски наличия уязвимых зависимостей. Давайте посмотрим на некоторые из этих рисков.
- Безопасность. Некоторые пакеты могут содержать уязвимость в системе безопасности в определенной версии. Отсутствие обновления до более новых версий, в которых исправлена уязвимость, делает проект уязвимым.
- Производительность. Использование старых пакетов может означать, что некоторые оптимизации производительности в последних версиях этих пакетов отсутствуют. Таким образом, общая производительность проекта также может не достичь своего полного потенциала.
- Качество: некоторые пакеты могли устареть. Использование этих пакетов в проекте создает уязвимость, из-за которой проект может выйти из строя, если устаревшие пакеты вдруг станут недоступны.
- Лицензирование. Программный проект связан не только с лицензиями его прямых зависимостей, но и с лицензиями используемых транзитивных зависимостей. Важно отслеживать лицензии всех зависимостей, чтобы компания не брала высокие комиссии за использование несовместимых лицензий на программное обеспечение.
Теперь давайте рассмотрим некоторые передовые методы управления зависимостями.
Надлежащая практика
Управление зависимостями проекта может привести к некоторым проблемам. Как узнать, когда зависимость уязвима? После выявления уязвимой зависимости, как изменения, связанные с обновлением зависимости, повлияют на существующую кодовую базу?
Давайте посмотрим на некоторые передовые практики, которые может внедрить команда разработчиков.
- Автоматизация. Обновление зависимостей может отнимать много времени у команды разработчиков. Как мы видели ранее, использование для этой цели инструмента автоматизации может облегчить жизнь команде разработчиков.
- Расстановка приоритетов. Начните с понимания того, какие зависимости тесно связаны с ядром вашей системы, и уделите больше времени изучению влияния обновления этих зависимостей.
- Напишите политику. Написание политики для работы с уязвимыми зависимостями может помочь команде разработчиков продолжить работу, не сомневаясь в пути отслеживания при обновлении уязвимых зависимостей.
Применение описанных выше практик снизит риск наличия уязвимых зависимостей.
Подведение итогов
Каждый раз, когда запускается новый программный проект, приоритетом должна стать автоматизация управления зависимостями.
Если в компании есть специальная команда по безопасности или инфраструктуре, у этих команд будет процедура управления зависимостями. Однако в тех случаях, когда компания полагается на самодостаточные команды, которые несут ответственность за весь жизненный цикл проекта, команда должна изучить тему и настроить автоматизированный процесс для своего же блага.
При наличии этого процесса команде разработчиков будет намного проще отслеживать уязвимые зависимости и устранять их.
Следует применять простое правило: чем раньше и чаще можно просматривать зависимости, тем лучше.
Удачного кодирования!
Повышение уровня кодирования
Спасибо, что являетесь частью нашего сообщества! Перед тем, как ты уйдешь:
- 👏 Хлопайте за историю и подписывайтесь на автора 👉
- 📰 Смотрите больше контента в публикации Level Up Coding
- 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"
🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу
