Инфраструктура и деплой
Урок 7.6 — Инфраструктура и деплой
Что такое инфраструктура
Инфраструктура — это всё, на чём работает приложение: серверы, сети, операционные системы, хранилища файлов. Раньше компании покупали физические серверы. Сегодня большинство использует облако.
Облачные провайдеры
Облако — это арендуемые серверы и сервисы. Три крупнейших провайдера:
| Провайдер | Сокращение | Известные продукты |
|---|---|---|
| Amazon Web Services | AWS | EC2 (серверы), S3 (хранилище), RDS (БД) |
| Google Cloud Platform | GCP | GKE (Kubernetes), BigQuery |
| Microsoft Azure | Azure | Active Directory интеграции |
Тестировщику не нужно знать облако в деталях, но важно понимать: когда говорят "задеплоили на AWS" — это значит код запущен на удалённых серверах Amazon.
Docker: контейнеры
Docker позволяет упаковать приложение вместе с его зависимостями (библиотеки, версия Node.js, конфиги) в изолированный контейнер.
Зачем это нужно:
- Приложение работает одинаково на любом сервере — "у меня на компе работало" больше не оправдание
- Легко поднять несколько независимых сервисов
- Быстрое развёртывание на новых серверах
Для тестировщика Docker означает: тестовое окружение воспроизводимо и идентично продакшену.
CI/CD: автоматический конвейер
CI (Continuous Integration) — Непрерывная интеграция: Каждый раз, когда разработчик отправляет код, автоматически запускаются проверки: сборка, линтер, автотесты. Если что-то сломалось — пайплайн "краснеет" и код не идёт дальше.
CD (Continuous Deployment/Delivery) — Непрерывная доставка: После успешных проверок код автоматически (или полуавтоматически) деплоится на сервер.
Как тестировщик участвует в CI/CD:
- Твои автотесты (если ты их пишешь) запускаются в пайплайне — ты "страж ворот"
- Если тесты упали, деплой не происходит
- Ты можешь смотреть логи пайплайна, чтобы понять, что и где сломалось
Git: контроль версий
Git — система, которая отслеживает изменения в коде. Каждое изменение — это коммит с автором, временем и описанием.
Что важно знать тестировщику:
| Термин | Что это |
|---|---|
| Ветка (branch) | Параллельная версия кода для разработки отдельной фичи |
| Коммит (commit) | Зафиксированное изменение с описанием |
| Мёрж (merge) | Объединение ветки с основной веткой |
| PR / MR | Pull Request / Merge Request — запрос на проверку кода перед мёржем |
Тестировщик часто тестирует конкретную ветку (feature branch) до того, как она попала в основную.
Окружения (environments)
Приложение существует в нескольких параллельных копиях:
| Окружение | Кто использует | Данные |
|---|---|---|
| Development (dev) | Разработчики | Тестовые, постоянно меняются |
| Testing (QA) | Тестировщики | Тестовые, управляемые |
| Staging | Предфинальная проверка | Максимально близкие к боевым |
| Production (prod) | Реальные пользователи | Боевые данные |
Баг, воспроизводимый на staging, но не на prod (или наоборот), часто связан с разницей в конфигурации или данных окружений.
Что мы запомним
- Облако (AWS, GCP, Azure) — арендуемые серверы, на которых работает продакшен
- Docker — контейнеры обеспечивают одинаковую среду на всех серверах
- CI/CD — автоматический конвейер: тесты → сборка → деплой; тестировщик участвует как "страж"
- Git — контроль версий; тестировщик тестирует конкретные ветки до мёржа
- 4 окружения: dev → testing → staging → production; различие окружений объясняет "баг не воспроизводится"