← Теория
🚀 Блок 07 — CI/CD Ozon
Git · Docker · CI/CD · Pipelines · GitLab CI · Деплой
🌿 1. Git — контроль версий
Git — система контроля версий. Отслеживает все изменения в коде. Несколько разработчиков работают параллельно.
Основные понятия
| Понятие | Что это | Аналогия |
|---|
| Repository (repo) | Папка с кодом + история изменений | Проект |
| Commit | Сохранение (снимок) текущего состояния | Сохранить игру |
| Branch | Ветка — отдельная линия разработки | Параллельный мир |
| Merge | Слияние веток | Соединить два мира |
| Pull Request (PR) / MR | Запрос на слияние ветки + код-ревью | «Проверьте мои изменения» |
| Clone | Скачать репозиторий | Скопировать проект |
| Push | Отправить свои коммиты на сервер | Загрузить |
| Pull | Скачать чужие изменения | Обновить |
Workflow (как работает команда)
main — основная ветка (прод)
└── feature/DS-702 — ветка разработчика
└── пишет код → commit → push
└── создаёт Merge Request
└── код-ревью → тестирует QA
└── merge в main → деплой
Частые команды
git status # что изменилось
git add . # добавить все файлы
git commit -m "DS-702: fix login"
git push origin feature/DS-702
git pull origin main
git checkout -b feature/DS-702 # создать ветку
git log --oneline # история коммитов
На собе: "Git — контроль версий. Разработчик работает в feature-ветке, делает MR, QA тестирует, после ревью мержат в main. Я получала ветки для тестирования через MR."
🐳 2. Docker
Docker — инструмент для упаковки приложения в контейнер. Контейнер включает всё необходимое для запуска: код, библиотеки, настройки.
Зачем нужен
- «У меня работает!» — у разработчика работает, а на проде нет. Docker решает: контейнер одинаковый везде
- Быстро поднять окружение: одну команду → всё работает
- Изолированные среды: несколько проектов не конфликтуют
Основные понятия
| Понятие | Что это | Аналогия |
|---|
| Image (образ) | Шаблон для создания контейнера | Рецепт блюда |
| Container (контейнер) | Запущенный экземпляр образа | Приготовленное блюдо |
| Dockerfile | Инструкция для создания образа | Рецепт (шаг за шагом) |
| Docker Compose | Запуск нескольких контейнеров вместе | Заказ комплексного обеда |
Пример Dockerfile
FROM node:18 # базовый образ
WORKDIR /app # рабочая папка
COPY package.json . # копируем зависимости
RUN npm install # устанавливаем
COPY . . # копируем код
CMD ["npm", "start"] # запускаем
Частые команды
docker build -t myapp . # собрать образ
docker run -p 3000:3000 myapp # запустить контейнер
docker ps # запущенные контейнеры
docker stop <id> # остановить
docker-compose up # запустить всё из compose
На собе: "Docker упаковывает приложение в контейнер со всеми зависимостями. Контейнер одинаково работает на любой машине. Image = шаблон, Container = запущенный экземпляр. Docker Compose — для запуска нескольких контейнеров."
🔄 3. CI/CD — что это
CI/CD — автоматизация сборки, тестирования и развёртывания.
CI = Continuous Integration (Непрерывная интеграция)
- Разработчик пушит код → автоматически:
- Сборка проекта
- Запуск автотестов
- Проверка кода (lint)
- Если что-то упало → разработчик видит ошибку сразу
CD = Continuous Delivery / Deployment (Непрерывная доставка)
- После успешного CI → автоматически:
- Развёртывание на staging / production
- Rollback если что-то пошло не так
Pipeline (пайплайн)
Push → Build → Test → Deploy
┌─────────┐ ┌─────────┐ ┌──────────┐ ┌─────────┐
│ Push │ → │ Build │ → │ Test │ → │ Deploy │
│ (код) │ │ (сборка)│ │ (тесты) │ │ (стенд) │
└─────────┘ └─────────┘ └──────────┘ └─────────┘
↓ упал тест?
❌ Pipeline FAILED → не деплоим!
Стадии пайплайна
| Стадия | Что делает | Упало = ? |
|---|
| Build | Компиляция / сборка проекта | Код не компилируется |
| Lint | Проверка стиля кода | Нарушен стиль |
| Test | Автотесты (unit, integration) | Тест не прошёл |
| Deploy staging | Выкатка на тестовый стенд | QA не сможет тестировать |
| Deploy prod | Выкатка на прод (после ручного подтверждения) | Критично! |
На собе: "CI — автоматическая сборка и тестирование при каждом пуше. CD — автоматический деплой. Pipeline = цепочка стадий: build → test → deploy. Если тест упал — деплой не происходит."
🦊 4. GitLab CI
В Ozon стек — GitLab CI. Конфиг пайплайна описывается в файле .gitlab-ci.yml в корне репозитория.
Пример .gitlab-ci.yml
stages:
- build
- test
- deploy
build-job:
stage: build
script:
- npm install
- npm run build
test-job:
stage: test
script:
- npm run test
deploy-staging:
stage: deploy
script:
- deploy-to staging
when: manual # ручной запуск
Концепции GitLab CI
| Понятие | Что значит |
|---|
| Pipeline | Весь процесс от push до deploy |
| Stage | Этап (build, test, deploy) |
| Job | Конкретная задача внутри stage |
| Runner | Сервер, который выполняет jobs |
| Artifact | Файлы, которые сохраняются после job (например отчёт Allure) |
Где QA видит результаты
- GitLab → Merge Request → видит статус пайплайна (✅ passed / ❌ failed)
- Кликает → видит какие тесты упали
- Artifact — может скачать Allure-отчёт
На собе: "GitLab CI — пайплайн описывается в .gitlab-ci.yml. Стадии: build, test, deploy. QA видит статус пайплайна в Merge Request: если автотесты упали — MR не мержим."
🌍 5. Окружения (Environments)
| Окружение | Для чего | Кто тестирует |
|---|
| Local / Dev | Разработка, отладка | Разработчик сам |
| Staging / QA | Тестирование перед продом | QA (ты!) |
| Pre-prod | Финальная проверка, максимально похоже на прод | QA + команда |
| Production (Prod) | Реальные пользователи | Мониторинг + регресс |
Deploy flow
feature-ветка → review-app (для QA)
merge to main → staging (автоматически)
тег/релиз → pre-prod → production (ручное подтверждение)
На собе: "Основные окружения: dev → staging → pre-prod → production. QA тестирует на staging. Deploys на прод — после подтверждения и тестирования."
💬 Вопросы для самопроверки