Когда коту нечего делать
он переписывает скрипты сборки.
Хорошо когда скрипты сборки есть, и плохо когда их нет, а такое порой случалось.
Часть первая: когда компьютеры всё ещё продавали с дисководами но флешки
уже набирали популярность, а я ещё не работал там где я работаю сейчас,
на проекте был волшебный ant скрипт который делал две вещи:
а) собирал war-ку и
б) деплоил war-ку,
и не делал одну вещь:
в) не обновлял базу схему базы (данные обновлял).
So far so good, пока артефакт был один и деплоился он дропаньем в папку jboss-а.
С учётом того что его лечили по мелочи лечили несколько лет,
страшен он был как смертный грех.
Часть вторая: как из одного сделать два, а лучше пять. Первый раз я залез в скрипт
сборки когда начал разделять приложение на части, в итоге нужно было разделить
приложение на пять частей. Yes we can, но тут ant показал свою истинную сущность.
Оказалось что содержимое папки lib теперь не одинаково хорошо для всех модулей,
и скрипт стал обрастать classpath-ами. Конечно, большая часть там дублировалась,
что то дублировать забывали, что то действительно было разное. В каком порядке собирать
~5 модулей это конечно не rocket-science, target=clean один на всех, и для сборки модулей
по моему использовались зависимости между таргетами.
Часть третья: jar(dependency)-hell. ant стрипт конечно работал, но очень скоро стало
совершенно очевидно что так жить нельзя. Я даже пост написал тогда.
Сейчас я бы сказал "б*ля, ну возьмите maven", но тогда выбор пал в cторону gradle,
в целом решение было довольно разумное. Буквально за день я сделал свой собственный
maven сами знаете с чем. Это решило проблему с зависимостями на тестовых серверах
как бы не на целый год. Да, в IDE был треш, после того как ты забирал проект из
репозитория его нужно было ещё день настраивать.
Часть четвёртая: змий деплоич. На самом деле где то сразу перед третьим этапом
мы поняли что ant-ом деплоить нельзя. Мы как раз пришли к идее Continuous Deployment,
о реализации которой я тоже уже рассказывал. В контексте утилит сборки важно то для
плавного переключения, скрипт который должен управлять всей инфраструктурой,
он не то что бы должен быть сложным, но в нем нужно некторое количество IF-THEN-ELSE.
Ant тут опять сливал по полной, ну и слово за слово, мы написали скрипт деплоя
на python, а потом дёргали его сначала из ant, а затем уже и из gradle (в тестовом окружении),
ну и руками в продакшне. Не то что бы его нельзя было написать/переписать на gradle, но
gradle тогда был что то типа 0.9RC и его нужно было как то стрёмно ставить, а python есть
на всех linux машинах.
Часть пятая: первые слова на Идише. Постепенно, проблемы с настройкой проекта
о которых я говорил выше стали хроническими. Кроме того стало понятно что
модулей нужно чуть болье пяти, где то 30, и тут моя наколенная поделка на gradle
мягко говоря стала пасовать. Т.е. описать сборку и зависимости проблем не было,
проблема была в том что это не было никак связано с IDE (хорошо что тогда не пришла
в голову идея генерить pom-ки, было бы очень страшно).
ant-avy по моему так и не поддерживается нормально в ide, gradle стал поддерживаться
значительно позже и мне очень не нравилось что он тормоз. Так что отсnупать было не куда,
позади jar-hell, впереди mvn.
Часть вторая пятая: refucktoring зависимостей.
Оказалось что когда я остановился на gradle я сделал очень правильно,
потому как половины библиотек который мы использовали в репозиториях найти не удалось.
Так что первым делом пришлось поднимать свой, и долго долго его настраивать.
Потом был ещё долгий процесс переноса и отладки модулей на новый pom.xml.
Когда это всё таки удалось, оказалось что gradle больше не нужен, вся сложная логика
радо который он был выбран ушла в maven, а упаковать war-ки не совсем стандартным
способом оказалось проще через ant, да да. мы вернулись к ant.
Часть шестая: наши дни. В общем и целом всё шикарно, основные цели достигнуты,
ключевые проблемы решены. Проблемы как всегда есть, но они решаются имеющимися
средствами, тут бы и радоваться. Leaning curve для mvn конечно крутовата, но с опытом
приходит понимание - и вроде как оно так и надо. Но это не финал.
Часть седьмая: назад в будующее. Сейчас реально хочется большего. Кроме всяких мелочей
типа создавать модули по шаблону (это можно мавен научить, но нужно разобраться) хочется
что бы скрипт сборки стал реально smart в плане валидации того что он собирает.
Что бы можно было проверить что в этих файликах должны быть так, а в этих не должно быть.
Или например что бы он по репозиторию мог построить отчёт об изменениях по модулям
с прошлого релиза. Или что бы мог сам автоматом сравнивать структуры баз
по данным migrate. В общем много всяких прикольных мелочей который на maven/ant
делается очень сложно. Я пытался осилить тег script в ant, да, на ant реально можно писать
любую кастомную логику на js и даже никакие дополнительные зависимости не нужны.
Но когда я прикинул сколько времени у меня ушло на пару простых штук, и какой страшный
код в итоге получается - в общем, так делать можно, но это очень дорого.
С другой стороны, я же java разработчик, зачем мне писать код который работает
с кодом той же библиотеки migrate на js когда это можно делать как нормальный проект
в нормальных условиях современно IDE.
И вот что я придумал:
1. Есть маленький bat/sh скрипт который пакует параметры командной
строки в одно значение и передаёт его через "-Dargs=%*" в ant.
2. Есть маленький ant скрипт который проверяет checksum кода моего
модуля сборки написанного на java/maven и если сумма меняется пересобирает его.
3. Есть модуль на java в котором я планирую реализовать кастомную логику сборки
(конечно всё что можно делегируется в embedded maven, да, как бонус я получил
полную модель pom в java коде).
В принципе, всё кроме встраивания мавена получилось сделать за пару часов, ещё
пол дня я сегодня потратил на maven (там внутри guice оказывается).
У меня даже кое что уже собирается таким макаром (пока только как прототип, конечно).
Мораль: чем дальше в лес тем больше мне кажется что сборку нужно писать на том же
языке что и основной проект (речь не о C++). Потому что:
1. Это огромное наследования опыта и средств разработки (в ant дофига классной логики,
но зачем мне учить язык программирования xml под который нормальную среду
разработки по ходу уже никогда не сделают, когда можно сделать то же самое на java)
2. Искусственный барьер между скриптом сборки и инфраструктурой написанной
на java просто исчезает. Вместо того что бы парсить вывод migrate я теперь могу
использовать его внутреннюю модель данных, например.
Хорошо когда скрипты сборки есть, и плохо когда их нет, а такое порой случалось.
Часть первая: когда компьютеры всё ещё продавали с дисководами но флешки
уже набирали популярность, а я ещё не работал там где я работаю сейчас,
на проекте был волшебный ant скрипт который делал две вещи:
а) собирал war-ку и
б) деплоил war-ку,
и не делал одну вещь:
в) не обновлял базу схему базы (данные обновлял).
So far so good, пока артефакт был один и деплоился он дропаньем в папку jboss-а.
С учётом того что его лечили по мелочи лечили несколько лет,
страшен он был как смертный грех.
Часть вторая: как из одного сделать два, а лучше пять. Первый раз я залез в скрипт
сборки когда начал разделять приложение на части, в итоге нужно было разделить
приложение на пять частей. Yes we can, но тут ant показал свою истинную сущность.
Оказалось что содержимое папки lib теперь не одинаково хорошо для всех модулей,
и скрипт стал обрастать classpath-ами. Конечно, большая часть там дублировалась,
что то дублировать забывали, что то действительно было разное. В каком порядке собирать
~5 модулей это конечно не rocket-science, target=clean один на всех, и для сборки модулей
по моему использовались зависимости между таргетами.
Часть третья: jar(dependency)-hell. ant стрипт конечно работал, но очень скоро стало
совершенно очевидно что так жить нельзя. Я даже пост написал тогда.
Сейчас я бы сказал "б*ля, ну возьмите maven", но тогда выбор пал в cторону gradle,
в целом решение было довольно разумное. Буквально за день я сделал свой собственный
maven сами знаете с чем. Это решило проблему с зависимостями на тестовых серверах
как бы не на целый год. Да, в IDE был треш, после того как ты забирал проект из
репозитория его нужно было ещё день настраивать.
Часть четвёртая: змий деплоич. На самом деле где то сразу перед третьим этапом
мы поняли что ant-ом деплоить нельзя. Мы как раз пришли к идее Continuous Deployment,
о реализации которой я тоже уже рассказывал. В контексте утилит сборки важно то для
плавного переключения, скрипт который должен управлять всей инфраструктурой,
он не то что бы должен быть сложным, но в нем нужно некторое количество IF-THEN-ELSE.
Ant тут опять сливал по полной, ну и слово за слово, мы написали скрипт деплоя
на python, а потом дёргали его сначала из ant, а затем уже и из gradle (в тестовом окружении),
ну и руками в продакшне. Не то что бы его нельзя было написать/переписать на gradle, но
gradle тогда был что то типа 0.9RC и его нужно было как то стрёмно ставить, а python есть
на всех linux машинах.
Часть пятая: первые слова на Идише. Постепенно, проблемы с настройкой проекта
о которых я говорил выше стали хроническими. Кроме того стало понятно что
модулей нужно чуть болье пяти, где то 30, и тут моя наколенная поделка на gradle
мягко говоря стала пасовать. Т.е. описать сборку и зависимости проблем не было,
проблема была в том что это не было никак связано с IDE (хорошо что тогда не пришла
в голову идея генерить pom-ки, было бы очень страшно).
ant-avy по моему так и не поддерживается нормально в ide, gradle стал поддерживаться
значительно позже и мне очень не нравилось что он тормоз. Так что отсnупать было не куда,
позади jar-hell, впереди mvn.
Часть вторая пятая: refucktoring зависимостей.
Оказалось что когда я остановился на gradle я сделал очень правильно,
потому как половины библиотек который мы использовали в репозиториях найти не удалось.
Так что первым делом пришлось поднимать свой, и долго долго его настраивать.
Потом был ещё долгий процесс переноса и отладки модулей на новый pom.xml.
Когда это всё таки удалось, оказалось что gradle больше не нужен, вся сложная логика
радо который он был выбран ушла в maven, а упаковать war-ки не совсем стандартным
способом оказалось проще через ant, да да. мы вернулись к ant.
Часть шестая: наши дни. В общем и целом всё шикарно, основные цели достигнуты,
ключевые проблемы решены. Проблемы как всегда есть, но они решаются имеющимися
средствами, тут бы и радоваться. Leaning curve для mvn конечно крутовата, но с опытом
приходит понимание - и вроде как оно так и надо. Но это не финал.
Часть седьмая: назад в будующее. Сейчас реально хочется большего. Кроме всяких мелочей
типа создавать модули по шаблону (это можно мавен научить, но нужно разобраться) хочется
что бы скрипт сборки стал реально smart в плане валидации того что он собирает.
Что бы можно было проверить что в этих файликах должны быть так, а в этих не должно быть.
Или например что бы он по репозиторию мог построить отчёт об изменениях по модулям
с прошлого релиза. Или что бы мог сам автоматом сравнивать структуры баз
по данным migrate. В общем много всяких прикольных мелочей который на maven/ant
делается очень сложно. Я пытался осилить тег script в ant, да, на ant реально можно писать
любую кастомную логику на js и даже никакие дополнительные зависимости не нужны.
Но когда я прикинул сколько времени у меня ушло на пару простых штук, и какой страшный
код в итоге получается - в общем, так делать можно, но это очень дорого.
С другой стороны, я же java разработчик, зачем мне писать код который работает
с кодом той же библиотеки migrate на js когда это можно делать как нормальный проект
в нормальных условиях современно IDE.
И вот что я придумал:
1. Есть маленький bat/sh скрипт который пакует параметры командной
строки в одно значение и передаёт его через "-Dargs=%*" в ant.
2. Есть маленький ant скрипт который проверяет checksum кода моего
модуля сборки написанного на java/maven и если сумма меняется пересобирает его.
3. Есть модуль на java в котором я планирую реализовать кастомную логику сборки
(конечно всё что можно делегируется в embedded maven, да, как бонус я получил
полную модель pom в java коде).
В принципе, всё кроме встраивания мавена получилось сделать за пару часов, ещё
пол дня я сегодня потратил на maven (там внутри guice оказывается).
У меня даже кое что уже собирается таким макаром (пока только как прототип, конечно).
Мораль: чем дальше в лес тем больше мне кажется что сборку нужно писать на том же
языке что и основной проект (речь не о C++). Потому что:
1. Это огромное наследования опыта и средств разработки (в ant дофига классной логики,
но зачем мне учить язык программирования xml под который нормальную среду
разработки по ходу уже никогда не сделают, когда можно сделать то же самое на java)
2. Искусственный барьер между скриптом сборки и инфраструктурой написанной
на java просто исчезает. Вместо того что бы парсить вывод migrate я теперь могу
использовать его внутреннюю модель данных, например.