Автоматизация обновлений зависимостей в проекте Compose

Мы в Google рекомендуем использовать последние версии библиотек в ваших Android-проектах, так как они имеют больше функций и исправленные ошибки. Однако обновление версий и исправление критических изменений может оказаться сложным процессом, особенно если вы пытаетесь исправить множество версий одновременно. Автоматизация этого процесса уменьшает количество ошибок, но есть некоторые соображения, которые следует учитывать, если вы используете Compose.

Сокращение времени на поддержку с помощью автоматизации

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

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

Изменение версий обычно означает открытие файла сборки, в котором вы определяете свои зависимости или их версии, а затем переход к репозиторию Google Maven или Maven Central, чтобы выяснить, какие из них вам следует использовать. Обычно:

• Если вы используете стабильную версию библиотеки, вы обычно обновляетесь до последней стабильной версии (например, от 2.5.0 до 2.6.2).
• Если вы находитесь на нестабильном пути, вы выбираете либо более позднюю стабильную версию, либо более новый нестабильный артефакт той же версии (например, 1.2.0-alpha05 будет обновлен до  1.2.0-beta01 или 1.2.1, но не до 1.2.2-alpha01).
• Если есть новая основная версия библиотеки, вероятно, есть критические изменения, и вы должны сделать это обновление в своем собственном PR (например, с 1.2.5 до 2.0.1).

Android Studio предоставляет подсказки с предлагаемыми обновлениями библиотек (и поддержка каталогов версий появится в Android Studio Giraffe!), но вы также можете автоматизировать этот процесс двумя разными способами:

• С помощью внешнего сервиса, который отправляет PR в ваш проект с обновлениями. Примерами этого являются Dependabot от Github или Renovate.
• С помощью плагина, установленного в вашей кодовой базе, который обновляет зависимости по команде, например, refreshVersions или version-catalog-update-plugin.

Для Архитектурных семплов мы предпочитаем не загрязнять файлы сборки плагинами, которые разработчики могут не использовать, поэтому мы выбрали внешний сервис. В нашем конкретном случае мы используем Renovate, потому что Dependabot не поддерживает группировку зависимостей, что крайне важно, если вы используете Compose.

Автоматизация обновлений с зависимостями Compose

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

С Renovate мы группируем все обновления в один PR, используя директиву group:all (см. пример ее использования в одном из наших конфигурационных файлов). Это делает обслуживание еще проще, потому что нам нужно утверждать только один PR каждую неделю. Однако это означает, что каждый раз, когда выходит релиз Kotlin, наш проект Compose будет ломаться до тех пор, пока не будет выпущен компилятор Compose. Это не было бы большой проблемой, если бы не тот факт, что когда ваша сборка сломана и остальным обновлениям придется подождать.

Чтобы исправить это, вы можете сгруппировать обновления вместе. Идея состоит в том, чтобы отделить обновления Kotlin от других изменений, чтобы вы могли продолжать обновлять другие зависимости.

В Renovate это делается с помощью packageRules:

"packageRules": [
   {
      "matchPackagePatterns": [
         "androidx.compose.compiler:compiler"
      ],
      "groupName": "kotlin"
   },
   {
      "matchPackagePatterns": [
         "org.jetbrains.kotlin.*"
      ],
      "groupName": "kotlin"
   },
   {
      "matchPackagePatterns": [
         "com.google.devtools.ksp"
      ],
      "groupName": "kotlin"
   }
]

Эти правила создают группу с именем «kotlin» и добавляют в нее сам Kotlin, компилятор Compose и KSP.

При этом Renovate будет генерировать два разных PR для каждой ветки. Один для группы «kotlin», а другой для остальных зависимостей.

Kotlin PR содержит только обновления, связанные с Kotlin, как и ожидалось:

Пример PR только для обновления зависимостей Kotlin

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

Важной особенностью Renovate является то, что если вы добавите коммит в один из его PR, бот перестанет пытаться его обновить, позволяя вам вносить изменения. Это настраивается на умном дашборде (см. пример) и тут огромный выбор параметров конфигурации.

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

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

Источник