Comments 14
Простите, а чем этот Bazel так хорош, что нужно так срадать?
Об этом я писал здесь: https://habr.com/ru/company/joom/blog/718340/
Основная цель: сокращение времени сборки в несколько раз (до миграции среднее время на сборку было порядка 40 минут, после 12 минут).
При этом удалось оторвать кучу самопальных костылей и, в целом, сборка стала гораздо надёжнее.
это ж что там должно происходить чтобы оно собиралось 40 минут О_О
40 минут это был средний результат инкрементальной сборки на 7-ми машинках в параллель. По нашим прикидкам, на одной машинке с холодным кэшем должно было быть часов 15.
В основном это время уходило на линковку тестовых бинарей: каждый пакет с тестами собирается в отдельный исполняемый файл и на это уходит чудовищное количество времени и дискового пространства.
На втором месте собственно исполнение тестов.
Базель как демократия по Черчиллю - плохой, но все остальное еще хуже :)
Помимо всякого кэширования, базелем можно делать всякую мелкую встраиваемую автоматизацию, типа генерации моков (причем на лету). Можно отслеживать прямые и обратные зависимости, включая транзитивные. Плюс оно гвоздями не прибито к конкретному языку, можно одной и той же системой собирать гошечку, жяву и жаваскрипт.
В общем, много чего можно, но и ломает он тоже очень много чего. В контексте голанга, например, совсем ломает gopls и всю идею модулей, так что либо надо городить огороды с поддельным GOROOT, либо использовать интеллижопу IDE c поддержкой базеля, что гм, не всегда удобно.
Я так и не смог понять, как подружить IDE и Bazel...
Собственно из-за этого и пошли по пути, когда BUILD-файлы генерируются на базе исходного кода и go.mod-файлов, максимально повторяя go build-сборку.
На машинках разработчиков Bazel используется только для создания генерируемых .go-файлов, которые потом раскладываются в рабочей копии. В результате для большинства, кроме этого вызова генератора, Bazel никак не используется.
Эта схема оказалась на удивление удачной:
разработчикам не нужно воевать с Bazel;
IDE работает как работало;
генераторы получают возможность генерировать зависящие от компиляции данные (в нашем случае mock-и);
если нужно, разработчик может использовать Bazel как для сборки, так и для запроса зависимостей через
bazel query.
А вот тезис с поддельным GOROOT я не понял...
Поддельный GOROOT - это когда специально обученный костыль собирает все зависимости указанного пакета (пакетов) и в отдельной директории выстраивает окружения для голанга - создает go.mod, вендорит внешние зависимости, генерит все то, что генерируя базелем итд. В итоге с этим можно работать в любой иде, потому что gopls.
У интеллиж в принципе нормальный рабочий плагин для работы с базелем, умеет все что надо - и тесты запускать, и навигацию. Единственно что оооочень долго синкается проект. А у VSCode когда я в последний раз смотрел, все было достаточно печально с базелем
А просто распилить монолит нельзя?
"Монолит" это что?
Видимо то, что билдится 40 минут
Распилить проект и уменьшить связанность кода это благая цель.
Но в данном случае:
уменьшение связанности никак не конфликтует с оптимизацией инструментария сборки;
уменьшение связанности кода никак нельзя назвать "простым" процессом.
Достаточно маленькие модули компилятся за секунду или меньше. И не нужно пересобирать все целиком. Распилить монолит - да, непросто, но это - инвестирование в правильном направлении. А тут какое то сокрытие симптомов нездорового процесса
Вы не представляете масштаб проблемы: распил проекта на маленькие модули требует годы.
Даже если предположить, что проект волшебным образом распадётся на сотни маленьких слабо связанных модулей, то их всё равно нужно будет чем-то собирать.
К тому же сокращение времени на итерацию в CI делает рефакторинг заметно комфортнее.
Путь миграции с go build на Bazel