Сколько раз мы собираем ПО каждый день? Сколько раз за день код компилируется, тестируется и превращается в артефакты? Какие разнообразные сценарии возможны в казалось бы простой цепочке compile-test-assemble? Билд-системы из узкоспециализованных утилит превратились в мощный инструмент сборки, валидации, дистрибуции и автоматизации наших программных продуктов.
Это будет тематический доклад о том как настроить инструмент сборки для себя, а не против себя. Мы рассмотрим основные принципы работы Gradle DSL и возможности его расширения. Как и на чём их писать, как тестировать и как делиться результатами своего труда со своими коллегами.
Вместе с вами мы напишем автоматизированный сценарий сборки для проекта и покажем как ловко можно вставлять костыли всю силу и мощь Gradle 2.x.
4. Что будет
1. Немного о том как люди проекты собирали/собирают
2. Несколько жизненных примеров
3. Микросервисный подход к сборке проекта, детка)
a. Дизайн того, что мы хотим
b. Попробуем наивный императивный подход
c. Уменьшим количество боли. Напишем плагин
4. А что там с тестами
5. Немного о том как люди будут собирать проекты на Gradle
6. Резюме
7. Q&A
4
5. Где мы сейчас?
1. Немного о том как люди проекты собирали/собирают
2. Несколько жизненных примеров
3. Микросервисный подход к сборке проекта детка
a. Дизайн того, что мы хотим
b. Попробуем наивный императивный подход
c. Уменьшим количество боли. Напишем плагин
4. А что там с тестами
5. Немного о том как люди проекты будут собирать
6. Резюме
7. Q&A
5
8. Процесс
1. Исходные данные
a. Исходники ПО
2. Дополнительные ресурсы
a. картинки
b. настройки
3. Метадата
a. конфигурация IDE
4. Что то очень странное и
специфичное
Нечто
8
9. Процесс
1. Исходные данные
a. Исходники ПО
2. Дополнительные ресурсы
a. картинки
b. настройки
3. Метадата
a. конфигурация IDE
4. Что то очень странное и
специфичное
Нечто, что можно использовать
9
18. Где мы сейчас?
1. Немного о том как люди проекты собирали/собирают
2. Несколько жизненных примеров
3. Микросервисный подход к сборке проекта детка
a. Дизайн того, что мы хотим
b. Попробуем наивный императивный подход
c. Уменьшим количество боли. Напишем плагин
4. А что там с тестами
5. Немного о том как люди проекты будут собирать
6. Резюме
7. Q&A
18
19. Как бывает в жизни
1. ant
2. maven
3. gradle
4.
19
20. Keep calm and make MAR (not WAR)
task mar(type: Zip) {
archiveName = 'AutoGeneratedMar.mar'
destinationDir = project.libsDir
from "resourcebundles" // ← WTF?
from ('Portal/public_html') { // ← WTF?
include 'oracle/**/*.*' // ← WTF?
}
}
20
27. Где мы сейчас?
1. Немного о том как люди проекты собирали/собирают
2. Несколько жизненных примеров
3. Микросервисный подход к сборке проекта детка
a. Дизайн того, что мы хотим
b. Попробуем наивный императивный подход
c. Уменьшим количество боли. Напишем плагин
4. А что там с тестами
5. Немного о том как люди проекты будут собирать
6. Резюме
7. Q&A
27
28. Документация + Asciidoctor = ❤
1. Все любят AsciiDoctor
2. Все могут писать документацию с помощью AsciiDoctor
3. Позволяет комбинировать документы
4. Внешние документы
28
29. Как это выглядит
= Самая главная документация
В этом документе описано как быть самым главным и важным документом в мире
разнообразных документов
include::https://raw.github.com/asciidoctor/asciidoctor/master/Gemfile[]
include::../other.adoc[]
include::/home/tolkv/git/docs-0/superdoc.adoc[]
29
30. Волшебные инклуды
= Самая главная документация
В этом документе описано как быть самым главным и важным документом в мире
разнообразных документов
include::https://raw.github.com/asciidoctor/asciidoctor/master/Gemfile[]
include::../other.adoc[]
include::/home/tolkv/git/docs-0/superdoc.adoc[]
30
31. А как хотим? Ещё более волшебные
= Самая главная документация
В этом документе описано как быть самым главным и важным документом в мире
разнообразных документов
include::https://raw.github.com/asciidoctor/asciidoctor/master/Gemfile[]
include::gradle://gradle-advanced:service-with-deps:1.0/deps.adoc[]
include::gradle://:service/doc.adoc[]
31
32. Где мы сейчас?
1. Немного о том как люди проекты собирали/собирают
2. Несколько жизненных примеров
3. Микросервисный подход к сборке проекта детка
a. Дизайн того, что мы хотим
b. Попробуем наивный императивный подход
c. Уменьшим количество боли. Напишем плагин
4. А что там с тестами
5. Немного о том как люди проекты будут собирать
6. Резюме
7. Q&A
32
34. Где мы сейчас?
1. Немного о том как люди проекты собирали/собирают
2. Несколько жизненных примеров
3. Микросервисный подход к сборке проекта детка
a. Дизайн того, что мы хотим
b. Попробуем наивный императивный подход
c. Уменьшим количество боли. Напишем плагин
4. А что там с тестами
5. Немного о том как люди проекты будут собирать
6. Резюме
7. Q&A
34
35. Кто нам поможет?
1. apply plugin: 'java-gradle-plugin'
2. 'org.asciidoctor:asciidoctorj:1.5.4'
'org.asciidoctor:asciidoctor-gradle-plugin:1.5.3'
3. org.gradle.api.Plugin
35
37. Где мы сейчас?
1. Немного о том как люди проекты собирали/собирают
2. Несколько жизненных примеров
3. Микросервисный подход к сборке проекта детка
a. Дизайн того, что мы хотим
b. Попробуем наивный императивный подход
c. Уменьшим количество боли. Напишем плагин
4. А что там с тестами
5. Немного о том как люди проекты будут собирать
6. Резюме
7. Q&A
37
41. Не всё так радужно и с тестами
Feature Minimum
Version
Description
Inspecting executed tasks 2.5 Inspecting the executed tasks, using BuildResult.getTasks() and similar methods.
Plugin classpath injection 2.8 Injecting the code under test via GradleRunner.withPluginClasspath().
Inspecting build output in debug mode 2.9 Inspecting the build's text output when run in debug mode, using BuildResult.
getOutput().
41
42. Не всё так радужно и с тестами
Feature Minimum
Version
Description
Inspecting executed tasks 2.5 Inspecting the executed tasks, using BuildResult.getTasks() and similar methods.
Plugin classpath injection 2.8 Injecting the code under test via GradleRunner.withPluginClasspath().
Inspecting build output in debug mode 2.9 Inspecting the build's text output when run in debug mode, using BuildResult.
getOutput().
42
44. И что же делать?
1. Извращаться
https://github.com/bmuschko/gradle-docker-plugin
2. Nebula-test
https://github.com/nebula-plugins/nebula-test
3. Заниматься продвинутым юнит тестированием https://github.com/spring-
gradle-plugins/dependency-management-plugin
44
45. Где мы сейчас?
1. Немного о том как люди проекты собирали/собирают
2. Несколько жизненных примеров
3. Микросервисный подход к сборке проекта детка
a. Дизайн того, что мы хотим
b. Попробуем наивный императивный подход
c. Уменьшим количество боли. Напишем плагин
4. А что там с тестами
5. Немного о том как люди проекты будут собирать
6. Резюме
7. Q&A
45
47. Как это будет выглядеть в build.gradle
Объявление по типу:
model {
html(Document) {
name ‘mydoc.html’
}
txt(Document) {
name ‘mydoc.txt
}
}
Объявление по имени:
model {
document {
name ‘mydoc.doc’
}
}
47
58. Где мы сейчас?
1. Немного о том как люди проекты собирали/собирают
2. Несколько жизненных примеров
3. Микросервисный подход к сборке проекта детка
a. Дизайн того, что мы хотим
b. Попробуем наивный императивный подход
c. Уменьшим количество боли. Напишем плагин
4. А что там с тестами
5. Немного о том как люди проекты будут собирать
6. Резюме
7. Q&A
58
59. Выводы
● Императивный подход хорошо когда проект единичный
● Когда проектов много - надо писать плагины
● Декомпозируй, переиспользуй плагины
● Тестируй правильно:
○ сейчас Nebula или юнит-тесты
○ ждём допиленный GradleTestKit
● RuleBased-модель - будущее, которое пока можно только пощупать
59
60. Ссылки
Весь код находится здесь:
https://github.com/lavcraft/jpoint2016-gradle
Тут только плагин с тестами:
https://github.com/aatarasoff/documentation-plugin-demo
Статья про сравнение способов тестирования:
http://bit.ly/217tZEx
60