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

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

Взяв большую базу кода 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 минут в зависимости от изменения кода.

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

До этих улучшений скорости сборка обсуждалась на каждом собрании разработчиков. Так как об улучшениях речь не шла.