Современной тенденцией в базах кода является создание монорепозиториев, состоящих из нескольких связанных баз кода. Это может упростить управление рабочим процессом разработчика. Недостатком является то, что время сборки может увеличиваться, и это может быть усугублено использованием смеси языков в базе кода, например. Ява и Джаваскрипт.
Базы кода со временем растут. Есть способы справиться с этим, но в какой-то момент сборка должна быть усилена, чтобы восстановить свою скорость, поскольку она замедляется из-за своего размера.
Взяв большую базу кода Java/Javascript со средним временем сборки 12 минут, мы можем рассмотреть способы повышения производительности сборки.
Отличным инструментом для проверки вашей сборки является сканирование сборки Gradle, его можно добавить с помощью плагина build-scan.
plugins { id 'com.gradle.build-scan' version '1.12.1' } buildScan { licenseAgreementUrl = 'https://gradle.com/terms-of-service' licenseAgree = 'yes' }
Теперь вы можете запустить свою сборку:
./gradlew build --scan
В конце сборки он распечатает URL-адрес. Это ссылка на сводку сборки из Gradle. Здесь отображается информация о производительности сборки, например об использовании кэша сборки.
Теперь перезапустите сборку с включенным кэшированием.
./gradlew build --build-cache --scan
Gradle отлично справляется с использованием кеша для модулей Java, но для сборок JavaScript требуется некоторая работа.
Для поддержки кэширования задача должна реализовать @CacheableTask и иметь определенные входы и выходы. Это означает, что если Gradle уже запускал эту задачу с теми же входными данными, он может использовать кэшированные выходные данные вместо повторного выполнения задачи.
@CacheableTask class CacheableYarnTask extends com.moowork.gradle.node.yarn.YarnTask { } task runJSDeploy(type: CacheableYarnTask) { inputs.file("package.json") inputs.file("yarn.lock") inputs.file("webpack.js") inputs.dir("src") outputs.dir("$buildDir/bundles") outputs.cacheIf { true } args = ['deploy'] }
Gradle также поддерживает совместное использование кэшированных значений. Наилучший подход — разрешить сборке использовать собственный кеш и кешированные активы, созданные из сборок в вашей среде CI.
В вашем settings.gradle добавьте информацию о центральном кэш-сервере. Использование общего кэша сборки HTTP (например, предоставленного Gradle Enterprise).
ext.isCiServer = "true".equalsIgnoreCase(System.getProperty('ci')) buildCache { local { enabled = !isCiServer } remote(HttpBuildCache) { url = "${URL}" push = isCiServer credentials { username = "${USERNAME}" password = "${PASSWORD}" } } }
Для этой большой базы кода Java/Javascript среднее время сборки сократилось с 12 минут до 1–6 минут в зависимости от изменения кода.
Повышение скорости сборки оказывает огромное влияние на продуктивность и моральный дух команды. Чем больше база кода, тем больше команды, а медленная или нестабильная сборка оказывает комплексное влияние на способность людей создавать качественное программное обеспечение. Медленные сборки приводят к тому, что люди спешат выполнить коммит во время зеленых окон и не запускают наборы тестов локально. Это может привести к большему количеству красных отложений.
До этих улучшений скорости сборка обсуждалась на каждом собрании разработчиков. Так как об улучшениях речь не шла.