Вводная часть (со ссылками на все статьи)

Лет 10-15 назад, когда программы состояли из исходников и небольшого количества двоичных файлов с работой по сборке итоговых программ отлично справлялись всевозможные «?make». Однако сейчас современные программы и подходы к разработке сильно изменились – это:
множество различных файлов (не считаю исходников) – стили, шаблоны, ресурсы, конфигурации, скрипты, бинарные данные и.т.д;

• предпроцессоры;
• системы проверки стиля исходников или всего проекта (lint, checkstyle и т.д.);
• методики разработки, основанные на тестах, с их запуском при сборке;
• различного типа стенды;
• системы развёртывания на базе облачных технологий и т.д. и.т.п.

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

Мой путь в использовании систем сборки был непонятное_количество_*make -> ant -> maven -> gradle (то обстоятельство, что android Studio под капотом использует gradle меня сильно порадовало).

Gradle меня привлёк:

• своей простой моделью (из которой правда можно вырастить монстра, соизмеримого с самим создаваемым продуктом);
• гибкостью (как в части настройки самих скриптов, так и организации их распределения в рамках больших проектов);
• постоянным развитием (как и со всеми остальными вещами в разработке — тут надо постоянно изучать что-то новое);
• лёгкостью адаптации (знание groovy и gradle DSL обязательно);
• наличием системы plugin’ов, разрабатываемых сообществом — это и разные предпроцессоры, генераторы кода, системы доставки и публикации и прочее, прочее (см. login.gradle.org)

Ознакомиться с возможностями Gradle можно на сайте разработчиков в разделе документации (можно узнать всё!). Для тех, кто хочет сравнить gradle и maven есть интересное видео от JUG.

В моём случае скрипты для сборки выглядят таким образом:

,
где:

• build_scripts/build-tasks.gradle — все задачи для сборки с указанием их зависимостей;
• build_scripts/dependencies.gradle — описания зависимостей и способов публикации;
• build.gradle — основной скрипт, определяющий зависимые модули, библиотеки и включающий другие скрипты сборки;
• settings.gradle — перечень зависимых модулей и настройки самого скрипта (можно переопределить ч/з аргументы запуска gradle).

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

Tips

Из интересных вещей/советов, которыми я хотел бы поделиться, при настройке gradle в моём проекте есть следующие:

• Вынос версий артефактов (шарится по блокам модулей было скучным занятием)

  
  Объявляем блок с зависимостями:
  

  // project dependencies
  ext {
  COMMONS_POOL_VER='2.4.2'
  DROPWIZARD_CORE_VER='1.1.0'
  DROPWIZARD_METRICS_VER='3.2.2'
  DROPWIZARD_METRICS_INFLUXDB_VER='0.9.3'
  JSOUP_VER='1.10.2'
  STORM_VER='1.0.3'
  ...
  GROOVY_VER='2.4.7'
  // test
  TEST_JUNIT_VER='4.12'
  TEST_MOCKITO_VER='2.7.9'
  TEST_ASSERTJ_VER='3.6.2'
  }
  

  
  И используем его в проекте:
  

  project(':crawler_scripts') {
  	javaProject(it)
  	javaLogLibrary(it)
  	javaTestLibrary(it)
  
  	dependencies {
  		testCompile "org.codehaus.groovy:groovy:${GROOVY_VER}"
  		testCompile "edu.uci.ics:crawler4j:${CRAWLER4J_VER}"
  		testCompile "org.jsoup:jsoup:${JSOUP_VER}"
  		testCompile "joda-time:joda-time:${JODATIME_VER}"
  		testCompile "org.apache.commons:commons-lang3:${COMMONS_LANG_VER}"
  		testCompile "commons-io:commons-io:${COMMONS_IO_VER}"
  	}
  }
  

  
  
• Вынос настроек во внешний файл
  Создаём или уже имеем файл с конфигурацией:
  

  ---
  # presented - for test/development only - use artifact from ""/provision/artifacts" directory
  storyline_components:
    crawler_scripts:
      version: "0.5"
    crawler:
      version: "0.6"
    server_storm:
      version: "presented"
    server_web:
      version: "0.1"
  

  
  И используем его в проекте:
  

  import com.fasterxml.jackson.databind.ObjectMapper
  import com.fasterxml.jackson.dataformat.yaml.YAMLFactory
  
  buildscript {
  	repositories {
  		jcenter()
  	}
  	dependencies {
  		// reading YAML
  		classpath "com.fasterxml.jackson.core:jackson-databind:2.8.6"
  		classpath "com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.8.6"
  	}
  }
  ....
  def loadArtifactVersions(type) {
  	Map result = new HashMap()
  	def name = "${projectDir}/deployment/${type}/hieradata/version.yaml"
  	println "Reading artifact versions from ${name}"
  	if (new File(name).exists()) {
  		ObjectMapper mapper = new ObjectMapper(new YAMLFactory());
  		result = mapper.readValue(new FileInputStream(name), HashMap.class);
  	}
  	return  result['storyline_components'];
  }
  

  
  
• Использование шаблонов
  
  Это моя любимая часть — позволяет сформировать необходимые конфигурационные файлы из шаблонов.
  Формируем шаблоны:
  

  version: '2'
  services:
  ...
    server_storm:
      domainname: story-line.ru
      hostname: server_storm
      build: ./server_storm
      depends_on:
          - zookeeper
          - elasticsearch
          - mongodb
      links:
          - zookeeper
          - elasticsearch
          - mongodb
      ports:
       - "${server_storm_ui_host_port}:8082"
       - "${server_storm_logviewer_host_port}:8083"
       - "${server_storm_nimbus_host_port}:6627"
       - "${server_storm_monit_host_port}:3000"
       - "${server_storm_drpc_host_port}:3772"
      volumes:
       - ${logs_dir}:/data/logs
       - ${data_dir}:/data/db
  ....
  

  
  И используем его в проекте:
  

  // выполнить копирование скриптов для подготовки сервера
  task copyTemplates (type: Copy, dependsOn: ['createStandDir']){
  	description "выполнить копирование шаблонов"
  	from "${projectDir}/deployment/docker_templates"
  	into project.ext.stand.deploy_dir
  	expand(project.ext.stand)
  	filteringCharset = 'UTF-8'
  }

  
  В итоге получаете конфигурационный файл, данные которого заполнены значениями переменных, получившими значения в ходе работы скрипта.Однако необходимо отметить, что если вам потребуется более сложная логика с переменными (например скрытие при отсутствии значений) — вам потребуется другой движок шаблонов в системе сборке. Я эту ситуацию обошел используя формат YAML по ходу проекта.
  
  
• Использование списков и замыканий groovy для специфичной обработки конкретных модулей
  
  Это фактически обычное использование groovy в скрипте сборки, но мне это помогло решить пару нетривиальных задач.
  
  Объявляем или получаем переменные множественного значения:
  

  ext {
  	// образы, создаваемые docker'ом
  	docker_machines = ['elasticsearch', 'zookeeper', 'mongodb', 'crawler', 'server_storm', 'server_web']
  	// образы, создаваемые docker'ом для которых необходимо копировать артефакты
  	docker_machines_w_artifacts = ['crawler', 'server_storm', 'server_web']
  }
  

  
  И используем их в проекте:
  

  // выполнить копирование шаблонов для docker с подстановкой значений
  docker_machines.each { machine ->
  	task "copyProvisionScripts_${machine}" (type: Copy, dependsOn: ['createStandDir']){
  ...
  	}
  }
  

  
  
• Интеграция с репозитариями maven — больно громоздкое описание для включения в статью (и сама работа достаточно бесполезная с учётом наличия примеров в документации)
  
  
• Возможность задачи блоков зависимостей для модулей, копирование и вставка которых отсутствует для каждого модуля
  
  Объявляем блоки:
  

  def javaTestLibrary(project) {
      project.dependencies {
  		testCompile "org.apache.commons:commons-lang3:${COMMONS_LANG_VER}"
  		testCompile "commons-io:commons-io:${COMMONS_IO_VER}"
  		testCompile "junit:junit:${TEST_JUNIT_VER}"
  		testCompile "org.mockito:mockito-core:${TEST_MOCKITO_VER}"
  		testCompile  "org.assertj:assertj-core:${TEST_ASSERTJ_VER}"
      }
  }
  

  
  И используем их в проекте:
  

  project(':token') {
  	javaProject(it)
  	javaLogLibrary(it)
  	javaTestLibrary(it)
  }
  

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

Спасибо за внимание!