Из каких основных стадий состоит CI/CD пайплайн?

А, вот эта ваша CI/CD хрень, ну давайте разберёмся, что это за зверь такой, а то все умные слова кидают, а на деле-то пиздец как просто, если не загоняться.

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

Итак, этапы этого аттракциона:

1. Сборка (Build) Тут ваш код, этот набор букв и цифр, превращают во что-то осязаемое. Собирают, компилируют, если надо, пакуют в Docker-образ или какой-нибудь JAR-файл. Инструменты — Maven, Gradle, ну или docker build, куда ж без него. Примерно так: mvn clean package или docker build -t my-app:latest . — и поехали.

2. Статический анализ кода (Code Analysis) А вот тут начинается самое интересное. Код прогоняют через всякие сканеры, которые ищут, где вы накосячили, где уязвимости оставили или просто написали хуйню, которую потом поддерживать — пиздец. SonarQube, например, любит указывать на ваши косяки. В общем, профилактический разбор полётов.

3. Тестирование (Testing) О, ебать, вот где собака порылась! Тесты идут этапами, как обряд посвящения.

   • Модульные (Unit): Быстрые, как удар током, проверяют каждую мелкую функцию. JUnit, pytest — ваши лучшие друзья на этом этапе.
   • Интеграционные: Тут уже проверяют, как ваша штука общается с базой данных или другими сервисами. Чтобы не вышло, что вы всё написали, а оно с реальным миром не дружит.
   • E2E (сквозные): Это уже полный пиздец, симуляция действий пользователя. Selenium или Cypress тупо кликают по интерфейсу, как обезьяна, и смотрят, не развалится ли всё. Если пройдёт — уже хорошо.

4. Публикация артефакта (Artifact Publishing) Всё, что собрали и проверили, надо куда-то сложить, чтобы потом взять и использовать. Docker-образ заливают в реестр (Docker Hub, ECR), какой-нибудь пакет — в Nexus. Команда проще некуда: docker push my-registry.com/my-app:${BUILD_NUMBER}. Положил и забыл.

5. Развертывание (Deployment) Финальный акт! Сначала обычно выкатывают на тестовое окружение (staging), чтобы ещё раз всё потрогать руками. А уж потом — в бой, в продакшн. Умные ребята делают это с хитрожопыми стратегиями вроде blue-green или canary, чтобы если что — откатиться быстро и без боли. Инструменты — Kubernetes (kubectl apply), Ansible, Terraform — кто во что горазд.

А вот как это может выглядеть в конфиге GitLab CI (.gitlab-ci.yml). Смотрите, вроде страшно, а на деле — обычный YAML:

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "Собираем приложение..."
    - mvn clean package
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

test-job:
  stage: test
  script:
    - echo "Запускаем тесты..."
    - mvn test
    - npm run test:e2e

deploy-staging:
  stage: deploy
  script:
    - echo "Деплоим в staging..."
    - kubectl set image deployment/my-app-staging app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  environment:
    name: staging
  only:
    - main

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