Как происходит процесс деплоя изменений в Java-приложение?

А, ну это ж классика, блядь! Деплой — это как пытаться поменять колесо на машине, которая едет по трассе под горку, а ты при этом ещё и пьяный. Ёпта, сейчас разжую.

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

1. Для разработки (Ты в своём уютном болоте) Тут можно позволить себе всякие вольности, блядь.

• Хот-релоад (Hot Reload): Это когда ты изменил какую-то хуйню в коде, а приложение само подхватывает это, не умирая полностью. В Spring Boot есть DevTools, в IDEA — свои плюшки. Но не обольщайся, ёпта! Если ты поменял не просто строку, а, например, сигнатуру метода или структуру класса — тут тебе придётся делать полный рестарт, потому что JVM — старый консервативный пердун, который не любит, когда его ебут в мозг на ходу. Это как пытаться заменить двигатель у самолёта в полёте — иногда получается, а иногда просто пиздец.
• Локальный редеплой: Самый надёжный, хоть и тупой способ. В той же IDEA: Build -> Rebuild Project (это чтобы вся старая скомпилированная хуйня вылетела в трубу), а потом запускаешь приложение заново. Всё, чистый лист.

2. Продакшен (Тут уже не до шуток, тут пиздец) Запомни раз и нахуй: полностью заменить работающий код в JVM "на лету" — невозможно. Это как требовать от человека, чтобы он поменял скелет, не переставая бежать марафон. Не-хуй-ня. Поэтому стандартный сценарий — это сборка нового артефакта и его развёртывание. И тут уже варианты:

• Старый добрый монолит (WAR/JAR): Собираешь новый app.jar, заливаешь его на сервер вместо старого и перезапускаешь всё к хуям. Проблема? Downtime. Приложение на время умрёт. Если у тебя пять пользователей — похуй. Если пятьдесят тысяч — это уже пиздец и потеря денег.

  # Собираем новый артефакт (старый, кстати, лучше прибить, чтоб не путался)
  ./mvnw clean package
  # И запускаем свеженький
  java -jar target/myapp-1.0.0.jar

• Контейнеризация (Docker/Kubernetes): Вот тут уже начинается магия, блядь. Ты не лезешь в работающую JVM, ты просто запускаешь новый контейнер с новой версией приложения, а старый потом прибиваешь.

  1. Собрал новый Docker-образ (в нём уже твой свежий код).
  2. Запушил его в registry (типа склада образов).
  3. Сказал Kubernetes: "Эй, мудак, замени-ка старые поды на новые, вот тебе новый образ".

     # Dockerfile — инструкция по сборке образа
     FROM eclipse-temurin:17-jre # Берём JRE
     COPY target/myapp.jar /app.jar # Копируем наш свежий JAR
     ENTRYPOINT ["java", "-jar", "/app.jar"] # Команда запуска

     И Kubernetes потихоньку, как хитрая жопа, заменяет одни поды другими, стараясь, чтобы приложение не падало.

3. Как избежать простоя? (Стратегии, чтобы не выглядеть лохом) Если нельзя заменить код на лету, можно сделать так, чтобы пользователь даже не заметил подмены.

• Blue-Green Deployment (Сине-зелёное развёртывание): У тебя две абсолютно одинаковые среды — "синяя" (работает старая версия) и "зелёная" (разворачиваешь новую). Пока новая версия встаёт и прогревается, весь трафик идёт на старую. Как только зелёная готова — БАЦ! — переключаешь весь трафик на неё. Если что-то пошло не так — мгновенно откатываешься обратно на синюю. Красота, ёпта!
• Canary Release (Канареечное развёртывание): Ты не всем сразу даёшь новую версию. Сначала направляешь на неё, скажем, 5% трафика (как канарейку в шахту — если сдохнет, то только она). Если всё ок — постепенно увеличиваешь процент, пока все не перейдут. Осторожно и безопасно.
• Rolling Update (Постепенное обновление в Kubernetes): Это встроенная в K8s фича. Он сам, не спеша, убивает по одному поду со старой версией и создаёт под с новой, пока все не обновятся. Пользователь в идеале ничего не замечает.

Вот и вся философия, блядь. В разработке — можно пошалить, в продакшене — только через полную замену артефакта, но с умом, чтобы не получить пизды от бизнеса за простой.