На Хабре несколько раз публиковались статьи, где JRebel либо просто упоминался, либо выкладывалась информация, что вышла новая версия. При этом, не всем читателям было понятно, о чём вообще речь, и как данное ПО работает.

Как непосредственному участнику разработки данного продукта, мне хотелось бы прояснить некоторые моменты, почему JRebel существует и как он может помочь Java-разработчику.

Откуда ноги растут?

Изначальная проблема известна практически любому разработчику, который работает с Java: после каких-либо изменений в проекте, для того, чтобы увидеть результат, тратится довольно много времени на сборку и развёртывание в контейнере. На Хабре уже публиковались отличные статьи о том, как можно ускорить или автоматизировать процесс разработки, не стану повторяться. Но дело в том, что в упомянутых способах есть свои изъяны: далеко не все изменения возможно перегрузить в развёрнутом приложении штатными средствами; очень легко получить утечки памяти, которые приведут к надобности перезапуска контейнера. Технические детали хорошо расписаны в серии статей в нашем сайте — любопытных приглашаю почитать.

Куда уходит время?

Как выглядит цикл разработки web-приложения, в классическом виде:
1. Сделали изменения в коде (или в ресурсах)
2. Собрали JAR/WAR/EAR
3. Развернули полученный архив в контейнере
4. Открыли развёрнутое приложение, и, после некоторых манипуляций увидели результаты своего труда.

В зависимости от размера приложения, используемого контейнера, и некоторых других факторов, этапы 2, 3 и 4 могут занимать от нескольких секунд, до совершенно невменяемых цифр. Наша компания проводила опрос разработчиков относительно используемых технологий и времени которое затрачивается на развёртывание приложения. Как оказалось, в среднем на развёртывание тратится около 3 минут за раз, и около 10 минут в час. В плачевных случаях, где на развёртывание уходит более получаса, нет даже смысла спрашивать у человека, сколько раз в час он может повторить этот процесс. Ответ очевиден.

Когда перезапуск контейнера/приложения занимает считанные секунды, проблема, описанная выше, не ощущается так сильно. Однако, по мере роста и усложнения проекта, неудобства дадут о себе знать. Тут-то и можно задуматься: может быть, JRebel — это то, что вам нужно?

Прочитал интересную и полезную статью (1) — и захотел поделиться собственным опытом. В нашей фирме за 12 лет работы с одной (своей, Oracle-ориентированной) программой у сотен клиентов накоплен богатейший материал на тему апгрейда структуры БД.

Первоначально мы предполагали, что достаточно хранить в каждой БД номер версии последнего апгрейда и накатывать скрипты инкрементально, поднимая версию до нужной. Такая методика успешно использовалась в предыдущей версии нашей программы, работавшей с СУБД Paradox. Но с СУБД Oracle все пошло не так, у каждого клиента было собственное видение, какой должна быть его БД, и рассинхронизация версий стала неизбежным злом. Привычная методика апгрейдов по версиям стала постоянно приводить к ошибкам, на которые уже никто и не обращал внимание, и рассогласование структур продолжалось несколько лет. В итоге у каждого клиента оказалась собственная, не идентичная никакой другой, структура БД, а клиентская часть программы как-то должна была с этим бороться.

В какой-то момент руководство поручило вплотную заняться проблемой апгрейдов БД ведущему программисту фирмы (мне) — человеку творческому, предпочитающему потратить больше времени, но избежать рутинной работы. И тогда был разработан инструмент, позволивший практически свести на нет различия в структурах БД у всех клиентов. Об этой технологии я и хочу рассказать мировому сообществу.