В некоторых проектах сборке отводится роль Золушки. Основные усилия команда сосредоточивает на разработке кода. А самой сборкой могут заниматься люди, далёкие от разработки (например, отвечающие за эксплуатацию, либо за развёртывание). Если сборка хоть как-то работает, то её предпочитают не трогать, и речь об оптимизации не заходит. Вместе с тем в больших гетерогенных проектах сборка оказывается достаточно сложной и к ней вполне можно подходить как к самостоятельному проекту. Если же относиться к сборке как к второстепенному проекту, то в результате будет получен неудобоваримый императивный скрипт, поддержка которого будет в значительной степени затруднена. В этой заметке мы рассмотрим, по каким критериям мы выбирали инструментарий, а в следующей — каким образом этот инструментарий используем. (Есть также перевод на английский.)  Модель сборки проектов во всех рассматриваемых инструментах представляет собой направленный граф без циклов (орграф, DAG), а не иерархическую структуру, типичную для структурного подхода (когда процедура вызывает другие процедуры, а затем пользуется результатами). Связано это с тем, что при разработке проекта вносятся небольшие изменения и бо́льшая часть операций по сборке не требуется. То есть организация проекта в форме орграфа является основой для того, чтобы выполнялись только те действия, которые необходимы для ближайшей задачи, тем самым часто используемые операции будут выполняться достаточно быстро. Узлами в графе являются цели или задачи. Цели — результаты, которые необходимо достичь; а задачи — операции, которые надо выполнить, чтобы достичь текущей цели. При этом задача может быть запущена только в том случае, когда все зависимости удовлетворены. Такая модель схватывает структуру проекта и позволяет достигать не одну конечную цель, а несколько разных целей, на основе общей системы целей/задач. Эти несколько разных целей сосуществуют вместе и их подзадачи пересекаются. Например, сборка, тестирование и генерация документации взаимосвязаны как раз таким образом. Поверх этой основной модели в ряде инструментов реализованы более высокоуровневые модели. При написании программ часто противопоставляются императивный и декларативный стили программирования. Под императивным стилем понимается описание последовательности действий, описывающих, как прийти к какому-то результату. Причём сам результат не описывается. При использовании декларативного стиля описывается желаемый результат, что мы хотим получить. Последовательность действий при этом выбирается инструментом самостоятельно. Такое разделение в некоторой степени условно. Сравним, например, такие программы: и Второй пример выглядит более декларативным, хотя разница всего лишь в названии функции. Здесь можно отметить, что код, являющийся императивным на одном уровне абстракции, может оказаться декларативным на другом уровне абстракции. В описанной выше модели структура целей может считаться декларативной, т.к. мы называем желаемый результат, а описание шагов по достижению какой-либо цели является императивной программой. В некоторых инструментах, рассмотренных ниже, могут быть и другие декларативные элементы. При старте проекта иногда бывает можно оценить, насколько сложной окажется интеграция проекта. В нашем случае оказалось, что требуется собирать несколько модулей node.js, несколько go-lang, осуществлять развёртывание нескольких модулей terraform (и ни одного jvm-модуля). В других аналогичных проектах, развивавшихся "органически", сборка осуществлялась с использованием make, а в скриптах сборки использовались bash, perl, python, php и др. Механизм сборки было трудно поддерживать, производительность оставляла желать лучшего и ряд возможностей не был реализован. Для нового проекта мы задумались, какой инструмент взять за основу системы сборки. Оценили такие варианты: Эта программа создана достаточно давно, широко применяется во многих проектах и, в целом, позволяет реализовывать сборку достаточно больших и сложных проектов. Плюсы Минусы В отсутствии ограничений, в скриптах сборки можно встретить  Такие неожиданности затрудняют поддержку и делают сборку небезопасной операцией. Maven стал революцией в системах сборки в момент своего появления. Идеи декларативного описания проектов, широкого применения конвенций, использования плагинов, хранения артефактов в репозиториях, использования системы идентификации, включающей версии — всё это обеспечило признание и широкое использование во многих JVM-проектах по сей день. Плюсы Минусы Отсутствие императивных скриптов является и плюсом и минусом. С одной стороны, декларативный подход обеспечивает жёсткое разделение кода и модели, с другой стороны, задачи сборки зачастую требуют отдельных вставок императивной логики, и решение таких задач в maven'е мучительно. Sbt — инструмент сборки Scala-проектов. Появился примерно в то же время, что и gradle. Плюсы Минусы Sbt в целом выглядит как специализированная система для сборки Scala-проектов, нежели чем универсальный инструмент сборки любых проектов. Gradle появился в 2007 году в качестве ответа на основные ограничения maven — отсутствие императивного кода, трудность реализации плагинов, неудобство при нестандартных операциях. Gradle базируется на идеях, предложенных Maven'ом, развивает их и меняет акценты. Основными частями модели gradle являются: Важным усовершенствованием стало использование DSL (domain specific language),
основанного на императивном языке, с помощью которого формируются элементы декларативной модели,
а также решаются императивные задачи. Плюсы Минусы Изначально gradle использовался с помощью groovy-DSL. В дальнейшем был разработан DSL на основе Kotlin'а. Плюсы Kotlin'а Минусы По итогам сравнения имеющихся инструментов сборки проекта мы решили попробовать в нашем проекте реализовать сборку и CI/CD с использованием gradle/kotlin. Этот вариант обладает рядом преимуществ в сравнении с реализацией сборки проекта на основе make/shell. Ниже приведены сравнительные преимущества gradle/kotlin по отношению к make: Преимущества: Недостатки: В следующей части рассмотрим некоторые особенности применения gradle/kotlin к сборке не-JVM проектов. Хотелось бы поблагодарить nolequen, Starcounter, tovarischzhukov за конструктивную критику черновика статьи. Scala архитектор