Привет.

Разработчики. Девопсы. Релиз-инженеры.

В продолжение темы http://www.sql.ru/forum/1296296/i-snova-o-skorosti-zapuska-spring-prilozheniya
Тема неплохая. И она натолкнула меня на некоторые мысли.Поэтому я решил
поднять более общий вопрос.

Итак. Сборка! Собственной персоной.


Что хотелось-бы обсудить
- Сборщики. Ant/Maven/Gradle.
- CI. Jenkins/Hudson/Teamcity.
- Файловые системы. ZFS. BtrFS. e.t.c. Файловые системы на базе оперативной памяти. Tmpfs/Ramfs. e.t.c.
- Чекаут бранчей. Git/SVN. Скорость.
- Оптимизация модульных и интеграционных тестов. Моки.
- Клонирование схем БД.
- Компилляция. Параллелизм компиллятора. Хитрости. AOT. Модули. Кодогенерация.
- Maven-репозитарии. Конфиги. Прокси. Как часто обновляются снапшоты.
- Рутина разработки. Свитч бранча. Шелв. Гит-стеш.



Вобщем поделитесь опытом у кого чего как собирается на проектах.
Без раскрытия бизнес-тайн прошу поделится таймингами. Сколько времени
идет компилляция? Сколько классов. Строк кода. E.t.c.

Сборщики. Кто переходил с maven на gradle? Каков эффект?

У кого как идут модульные тесты с базой? Как вы подготавливаете схему?

Вобщем на чём у кого идет самый большой затык? И как оптимизируете?

Basil A. SidorovВарианты ускорения сборки тоже могу предложить, но это насколько кустарно и так не вписывается в сложившуюся инфраструктуру, что не имеет практической ценности.
Ну... я не расчитывал это сходу. Собственно... я и искал кустарных советов из которых впоследствии
можно сделать какие-то выводы. Например. Предположение о том что javac оптимизировать на нашем
уровне вобщем-то невозможно да и бох с ним. Мы эту тему обойдем. А вот чем еще занят maven
и gradle во время билда - это большой вопрос.

Alexey TominSVN забудь. HG не пробовал. checkout быстрее, но может выстрелить больно.

SVN я пытаюсь забыть уже 5 лет но заказчик мне периодически его втюхивает.
HG мне понадобилось установить 1 раз для того чтобы посмотреть что-то в OpenJDK.

Alexey TominМоки в модульных, стенды в интеграционных. Всё просто.

Хм... что такое стенды? Не слышал. Может это неудачный перевод англоицизма?

Alexey TominНикогда. Все зависимости от других (даже своих) проектов- только на версии, никаких снапшотов.

У нас на последних проектах транковские зависимости кодключены как SNAPSHOT.
Это зависимости между модулями или частями одного и того-же крупного проекта.
Дефолтную политику обновления я не знаю но возможно 1 сутки на кеширование.

Alexey TominAOT нафиг (потом сложно понимать и отлаживать). Кодогенерация- тоже лучше обойтись средствами языка (kotlin рулит). Параллелизм- хороший в gradle, ещё лучше в bazel. У maven есть глюки.

Здесь я немного уклоняюсь в сторону от билда. Просто хотел узнать каков полезных эффект АОТ для
обычной каждодневной рутины в разаработке.

Старт-тайм релизов у заказчика - пока не интересует. (По сабжу пофиг т.к. ентерпрайз стартует
глубокой ночью и еще много часов выполняет подготовительные действия к отркрытию биржевого дня.
Поэтому глубоко пофиг).

Alexey Tomin2-3 репозитория открытые в 2-3 копиях IDEA.

Я не знаю. Я наверное не научился корректно исопльзовать Гит. Его встроенный шелв - неудобен. Потом хер найдешь.
Обычно бывает так. Ты - сидишь в глубоком трансе. Погружен в исследования. Тут прилетает срочная просьба
пофиксить баг. Ты чертыхаешся открываешь статус. Овер 100 изменённых файлов. Надо закоммитить? Нет не все.
Часть откатить. Не коммитить грязь. Часть не проиндексирована хотя надо закоммитить. Надо подумать о грамотном
коментарии в коммиту.

В результате я обкладываю матом заказчика. Гит и одного финского парня. Закываю проект. И делаю еще один
git clone c последнего релиза в другой каталог. и фикшу там. Через месяц работы - вся файловая система - в копиях одного репозитария.

Alexey TominТесты хадуповских джоб- в одном продукте вынесли работу с хадупом в отдельный модуль, в другом bazel и он решает. Вроде всё из общеполезного.
Спасибо за ссылки на bazel. Никогда не юзал. Почитаю.

Андрей Панфиловmayton- Сборщики. Ant/Maven/Gradle.
Если говорить про CLI, то Gradle однозначно лучше остальных: он понимает зависимости между модулями, поэтому если изменения были в связанных модулях, то он нормально все скомпилирует без выполнения clean (хотя с упаковкой war и оверлеями у него однозначно всос), maven зависимости между модулями толком не умеет, поэтому в нем приходится делать или clean package/install, либо писать скрипты с вызовом сборки отдельных модулей либо в IDE настраивать все те же самые вызовы. Кроме этого, как только мы начинаем делать что-то более менее сложное на maven, то узнаем, что maven - это такая помойка из плагинов разной степени паршивости: какие-то понимают конфигурацию одним образом, какие-то другим, какие-то умееют использовать classpath проекта, какие-то не умеют. Однако, как только мы из CLI переходим в IDE то начинается ад и содомия: IntelliJ на проектах gradle тупит просто до невозможности, поэтому то что мы можем выиграть при сборке мы потеряем на разработке (к слову сказать IntelliJ толком не умеет ни maven, ни git, ну и вообще ничерта не умеет - застряли где-то далеко в прошлом)
Насчет плагинов - согласен. С самого начала изучения maven у меня было стойкое ощущение
что я работаю со сборной солянкой каких-то стрёмных плагинов большая часть из которых
плохо документирована. Плохо поддерживается и совершенно не поддерживает опции
параллелизма (по последнему пункту я дам пруф но чуть позже).

На gradle я поглядываю давно. Но пока не имею никакого плана относительно миграции.
До миграции я должен сам для себя уяснить маппинг между flows/goals/phazes/profiles/modules
из maven и такими-же сущностями градл. И иметь хотя-бы в голове приблизительный план действий. Что? Куда? Как? Риски?
Совместимость? Плагины?

Вобщем пока этого плана нет - задача миграции не то что невыполнима. А скорее имеет бесконечный
эстимейшен.

По поводу IDE Initellij. Мы на проекте не используем встроенный сценарий компиллятора этой среды.
Практически всегда работает maven. Пожалуй исключение составляют модульные тесты и дебаг-мод.
Эти штуки не работают без частичной компилляции.

По поводу что Jetbrains не умеет работать с git. Я обычно использую только часть возможностей UI.
Например очень важно уметь делать merge. Это главный поинт от версионного контроля. И если
есть подозрение что Ide что-то делает не так - я тут-же переключаюсь в CLI и проверяю как там.

Андрей Панфиловmayton- CI. Jenkins/Hudson/Teamcity.Jenkins - тоже, еще та помойка (в принципе как и все движняки с докером): они основной целью сборки в докере считают предотвращение того, чтобы кто-то через пулреквест не пульнул rm -rf /, а если ты законопослушный разработчик на предприятии и хочешь красиво прогонять интеграционные тесты, то иди и пердолься с этими дженкинсами и докерами, собственно настроить в дженкинсе что-то и можно, но вот когда сборка/тесты валятся по какой-то причине - попробуй пойти и объяснить рядовому разработчику, как весь этот колхоз запустить самому и отдалить, поэтому по большому счету jenkins тянет разве что на запускалку mvn clean verify по расписанию, а на большее он не способен: от него была бы хоть какая-то польза если бы он умел хотябы деплоить нормально, но он и этого не умеет.
Ну... мне сложно его сравнивать. Видимо мне надо поработать с Докером чтоб понять ваши обиды.
А так... как бесплатный инструмент - он вполне себе оправдывает свое существование.

Valentin Kolesnikovmayton,

Jhipster4/spring 4.3 проект собирается maven-ом.

Командля для обновления на сервере:

git push heroku master.

Репозиторий с проектом: https://github.com/jscrdev/jhipster4-demo

С уважением, Валентин
А сколько времени у вас занимает сборка? Я попробовал несколько экспериментов.
(мне в данном случае все равно какой проект брать. Можно было из опенсорца
взять Hibernate например. Но я взял ваш Jhipster.


Эксперимент 1.
Конфигурация:



Я использовал сценарий clean+install без тестов.
Предварительно очищал m2/rep. Поэтому первый замер чуть дольше за счет скачивания зависимостей.


Вобщем mvn clean install -DskipTests занимает 219 секунд. В стабилизированном состоянии.

Второй эксперимент . Все тоже самое. Очищаю m2. И монтирую один его каталог как tmpFs
и указываю размер 300м.

Кусок скрипта. (Часть команд требуют sudo).



Цифры стали чуть лучше. Однако улучшение незначительно.




Третий эксперимент.
Те-же самые условия. Только я переношу исходники тоже в каталог под файловой системой tmpfs.
900м - это полный размер исходников + бинари после финала package.








Почти никаких изменений. С инициализацией .m2 есть непонятные задержки. Очевидно плавает сеть.
Появилась идея в дальнейшем - отследить что за трафик бегает в глобальный репозитарий. Надо настроить
прокси с логиированием. Но это займет у меня какое-то время.

В течение всех экспериментов я запускал htop и наблюдал нагрузку на memory. У меня на борту 8Г. И во всех
случаях я не превышал 5.5Г. Надеюсь что захода в paging у меня не было.

казинака вообще, все перечисленное в первом посте - это проблемы негров
проблема которая реально волнует шерифа - это простой системы, и глюки, из-за обновлений

типа обновили war на нескольких апп серверах, но т.к. абсолютно точно, консистентность гарантировать нельзя, то что с этим делать?

На правах топик-стартера я все таки попрошу вернуться в русло темы. А именно - оптимизации билда.
Обсуждение багов - давайте отдельным топиком.

Андрей ПанфиловТам основное время тратится на работу nodejs - толку дисковую подсистему оптимизировать здесь никакого нет, зато проект в целом показательный в плане "как не нужно делать", а именно:
1. гадить в корень проекта папкой src - дурной тон, лучше создавать сразу отдельный модуль
2. гадить версиями зависимостей, плагинов, настройками плагинов в основной pom.xml - дурной тон, лучше сделать оркестрирующий проект
3. всю шелуху от nodejs вынести в отдельный модуль, собрать из него war, в основном проекте подключить его оверлеем, закрыть профилем и собирать только по большим праздникам, после чего сборка будет занимать секунды, а не минуты.
Всё что вы написали - это интересно и я попытаюсь осмыслить. Но во первых я не являюсь nodejs разработчиком
и не представляю себе его технологический цикл разработки.

По поводу модулей - я с вами почти согласен. Но это когда есть основания предполагать что разработка или доработка
или фиксация багов будет затрагивать 1 модуль независимо от других.