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

Когда никто даже не подозревал

Совсем недавно по историческим меркам, но оочень давно по меркам IT индустрии люди писали код. Пусть, скажем, году так в 2000-ом. И особенность этой индустрии заключается в том, что со времён, наверное, после громоздких ЭВМ, код, написанный программистами перемещается на другой компьютер для работы. Сейчас этот процесс модно называется “деливери”, а человек, который им руководит – “деливери менеджер”. Изюминка в этом всём, что код нужно было запустить после того как его перемещали на машину, где он должен был работать. Отсюда прямо следует две фазы – упаковка выполняемого кода и запуск на другом компьютере. И осуществлялось это самым незатейлевым способом. Программисты неким образом складывали свои файлики и писали краткую иструкцию, что нужно сделать чтобы это всё заработало. Думаю все слышали про так называемые ридми файлы.

Надо с этим жить

Итак у нас есть инструкции и файлы программы. Всё хорошо работает. Но. Есть у человека свойство лениться. Уж не хочет очень один и тот же человек делать одно и то же по нескольку раз. Теперь давайте представим, что админ, который копирует, переименовывает, меняет файлы раз от раза, хочет свести свою работу к минимуму (или то же самое другими словами – не хочет делать свою работу). Он берёт и пишет батник в котором фактически автоматизирует работу по установке и запуску ПО.

Что-то начали подозревать

У админа значит есть батник, который делает за него его работу. Поэтому админ может ничего не делать, но есть ведь программист! Который, падла, постоянно пишет код. Поэтому однажды админ осознаёт, что всё упало. Разбирается и понимает, что инструкция по установке нового релиза претерпела, так сказать, незначительные изменения. Программист не знает ведь, что админ написал скрипт и нихрена не делает… Естественно совершенно здравое желание админа заставить программиста апдейтить скрипт для развёртки. Иначе админу опять прийдётся работать!

Но программист же умный. Он тут же говорит, что “я ваш баш не курю”, “я такое могу написать, что сервер сам уронится”, “я понятия не имею где будет приложение разворачиваться – мне писать (кол-во операционных систем)*скриптов?”.

После этого ситуация, так сказать, на некоторое время подвисает. И работа “деливери менеджера” в этот период заключается в том, чтобы уворачиваться между какашками, которые метают друг в друга программисты и админы, пытаясь переложить друг на друга свою работу.

Вот где-то тогда и появился Ant. Он закрыл все вопросы о кроссплатформенности, поэтому “тугие” в админских делах программисты могли уже писать сами как им надо там файлики копировать. Ну а админы по ламерски уже запускали ant build.xml.

“Деливери менеджеры” получили заслуженную передышку. Их задача сводилась к написанию ответственного письма в ответственное время. И они уже начали потихоньку примерять новую лычку “релиз менеджера” НО…

Надоело!

Тут опять программисты, ссуки. Их скорость написания приложений, а также фанатичная приверженность всякораным бест практисам и “не изобретению” велосипедов, породила хаос библиотек, которые нужно было откуда-то брать, где-то хранить и при сборке не только использовать для компиляции, но и как-то ими оперировать. Концептуально проблема решается очень элементарно – единым хранилищем всех библиотек. А поскольку в IT ничего простого не бывает, эта проблема не решалась очень долго и хаос библиотек ширился и процветал.

Когда уже стало совсем швах с развёрткой системы, программисты начали искать решение. Вместо того чтобы решить проблему с хранилищем библиотек, был изменён подход к самой сборке бинарников. Что с одной стороны упростило сборку однотипных небольших проектов, с другой стороны сделало практически невозможным гибко и быстро кастомизировать сборку под свои нужды.

Но поскольку с библиотечным адом maven более-менее справлялся, решили, что серебрянная пуля найдена и все на время успокоились. Начали оперировать новым бест практисом – модульностью. То что модульность в этом случае ограничивалась всего-лишь новой зависимостью и очень часто никакой больше нагрузки не имела – мало кого заботило. Благо, что maven сам эту зависимость и менеджил.

Ничто не вечно

Казалось бы, хранилище библиотек есть, сборка в один клик работает. Но. Как всегда бывает, когда строишь дом из современных материалов на старом и гнилом фундаменте – потерпишь факап. Что собственно и случилось с maven. Если говорить грубо, то я бы сказал, что этот фреймворк выебал сам себя. То количество тупых и нелогичных затыков, с которыми встречаешься в процессе работы – поражает. Особенно, когда нужно отойти от декларативной прямой и лайфсайкла, что требует maven. Поэтому что? Поправить фреймворк? К хуям! Напишем gradle!

Лично мне уже даже интересно на чём может зафакапиться этот очередной высер программерской мысли. Так что жду с нетерпением…