Опиши типичный CI/CD пайплайн для деплоя Java-приложения.

А, ну вот, смотри, классика жанра — как этот ваш Java-приклад запихнуть в трубу CI/CD, чтобы оно само собиралось, тестировалось и ехало на сервера, пока ты кофе пьёшь. Сейчас разложу по полочкам, но с приправами.

Этапы этой нашей волшебной конвейерной ленты (возьмём для примера GitLab CI, ибо популярно):

1. Сборка (Build): Ну, тут всё просто, как три копейки. Берём и компилим.

   build:
     stage: build
     script:
       - mvn clean compile
     artifacts:
       paths:
         - target/

   Собрали — положили артефакты в карман, чтобы на следующем этапе не начинать с пустого места.

2. Тестирование (Test): А вот тут уже интереснее. Запускаем тесты. Если они все зелёные — молодцы. Если нет — ну, ёпта, иди фикси, пока тебя не зафиксили.

   test:
     stage: test
     script:
       - mvn test
     dependencies:
       - build

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

3. Статический анализ кода (Code Quality): Это когда умный дядька-робот (типа SonarQube) приходит и говорит: «А у тебя тут, дружок, код пахнет, как старые носки в спортзале». Полезная, блядь, вещь, хоть и нервы треплет.

   sonarqube-check:
     stage: test
     script:
       - mvn sonar:sonar

4. Создание артефакта (Package): Теперь упаковываем наше добро в красивую банку — JAR-файл.

   package:
     stage: package
     script:
       - mvn package -DskipTests
     artifacts:
       paths:
         - target/*.jar

   Тесты уже прогнали, поэтому -DskipTests, чтобы время зря не терять.

5. Создание Docker-образа: А теперь — магия! Засовываем нашу банку в контейнер. Собираем образ, тэгируем его хэшем коммита (чтобы потом не было мухлежа) и пихаем в registry.

   docker-build:
     stage: package
     script:
       - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
       - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

   $CI_COMMIT_SHA — это наш золотой ключик. Один коммит — один неизменяемый образ. Хули тут менять-то?

6. Деплой в staging-окружение: Выехали! Катим свежий образ на тестовый стенд (staging). Обычно это происходит автоматом при мерже в основную ветку.

   deploy-to-staging:
     stage: deploy
     script:
       - echo "Deploying to Kubernetes..."
       - kubectl set image deployment/myapp myapp=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -n staging
     environment:
       name: staging
     only:
       - main

   Сказали куберу: «Слушай сюда, дружище, замени-ка под капотом у деплоймента myapp образ на вот этот, новенький». И он послушно меняет.

7. Деплой в production (ручной или с approval): А вот это уже серьёзно, детка. На прод — только с санкции. Поэтому ставим when: manual.

   deploy-to-prod:
     stage: deploy
     script:
       - kubectl apply -f k8s/production.yaml
     environment:
       name: production
     when: manual

   Сидишь, смотришь на staging, всё ли работает. Потом глубоко вздыхаешь, крестишься и жмёшь кнопочку. Волнение, блядь, пиздец.

А теперь, блядь, ключевые практики, без которых это всё — просто цирк:

• Инфраструктура как код (IaC): Все эти твои кубернетисовские deployment.yaml и service.yaml должны лежать в том же гите, рядом с кодом. Чтобы не было вот этого: «А на моей машине работало!» — «Ага, а конфиги у тебя в голове, да?».
• Неизменяемые артефакты: Как уже говорил — один коммит, один тег образа. Никаких «ой, я тут на проде конфиг поправил прямо в поде». Нахуй такие практики, они от лукавого.
• Откат (Rollback): Всё просто, как двери. Если на прод накатилась хуйня — говоришь куберу: «Верни-ка, браток, образ на предыдущий тег». И он, сука, возвращает. Красота.
• Мониторинг: После деплоя не убегаешь пить пиво. Сначала смотришь в Grafana или куда ты там смотришь — не полетели ли метрики в тартарары. Потом уже пиво.

Вот и вся нехитрая магия. Сделал раз — и потом только кнопки жать. Ах да, и молиться, чтобы интернет не отрубился в момент docker push.