Какие знаешь нерелизные системы?

Обзор нерелизных (непродовых) систем в жизненном цикле разработки ПО

В контексте современной разработки ПО, особенно с практиками DevOps и CI/CD, использование изолированных от продакшена систем — это стандарт и необходимость. Нерелизные системы (часто называемые средами или эшелонами) создаются для безопасной разработки, тестирования, отладки и демонстрации функционала без риска для реальных пользователей и данных. Я разделю их по основным целям и этапам жизненного цикла.

Ключевые типы нерелизных систем

1. Среда разработки (Development, или Dev)

• Назначение: Основная среда для написания и первоначальной сборки кода разработчиками. Здесь код только появляется и проходит первичное "дымовое" тестирование.
• Характеристики: Часто локальная (на машине разработчика) или общая, но очень нестабильная. Данные — "мусорные" (mock, stub) или частично скопированы с других сред.
• Пример инструментов: Docker на локальной машине, мини-кластер Kubernetes (Minikube), локальные базы данных (SQLite, PostgreSQL в контейнере).

2. Среда интеграции / сборки (Integration / Build)

• Назначение: Среда для автоматической сборки приложения из кода, взятого из репозитория (например, Git), и прогона юнит-тестов и интеграционных тестов. Ключевое звено CI (Continuous Integration).
• Характеристики: Управляется системами CI (Jenkins, GitLab CI, GitHub Actions). Часто создается "на лету" для каждого билда или пулл-реквеста и уничтожается после прогона тестов.
• Пример конфигурации в GitLab CI:

  stages:
    - build
    - test
  build_job:
    stage: build
    script:
      - docker build -t my-app:$CI_COMMIT_SHA .
      - docker push my-app:$CI_COMMIT_SHA
  integration_test_job:
    stage: test
    script:
      - docker run my-app:$CI_COMMIT_SHA npm run integration-tests
  

3. Среда тестирования (Testing / QA)

• Назначение: Основная площадка для работы QA2. Здесь выполняется ручное тестирование, автоматизированное регрессионное тестирование (UI, API), а также нефункциональное тестирование (нагрузочное, безопасность).
• Характеристики: Максимально приближена к продакшену по конфигурации, но использует изолированные базы данных с тестовыми или анонимизированными данными. Стабильнее, чем Dev.
• Типы внутри: Часто делится на под-среды:

    *   **QA / Stage (Стабилизации):** Для приемочного тестирования (UAT) и финального регресса.
    *   **Performance / Load:** Специально "раздутая" среда для нагрузочного тестирования.
    *   **Security:** Среда для сканирования уязвимостей (SAST/DAST).

4. Среда предрелизная / стабилизации (Staging / Pre-production)

• Назначение: Критически важная среда-двойник продакшена. Используется для финальной проверки сборки (смоук-тест, санити), демонстрации заказчику (UAT - User Acceptance Testing), отработки процедуры развертывания (деплоя) и отката (роллбэка).
• Характеристики: Конфигурация, инфраструктура и объем данных должны быть идентичны продакшену, за исключением точек взаимодействия с внешними платежными системами или шлюзами (там используются sandbox-режимы). Данные — анонимизированная копия прода.

5. Среда демонстрационная / песочница (Demo / Sandbox)

• Назначение: Для демонстрации возможностей продукта потенциальным клиентам, партнерам или для тренировок. Часто содержит заранее подготовленные сценарии использования.
• Характеристики: Может быть перезапускаемой "с нуля" или иметь возможность сброса данных до первоначального состояния.

Принципы работы с непродовыми средами

1. Изоляция: Сети, базы данных, сторонние сервисы (используются их тестовые/sandbox-версии) между средами должны быть изолированы. Прямой доступ из Dev или Test в продакшен-базу — грубейшее нарушение безопасности.
2. Управление конфигурацией: Конфигурация (URLы БД, ключи API) управляется через переменные окружения или специальные хранилища (Vault), а не жестко зашита в код.
3. Близость к продакшену: Чем ближе среда к релизу (Staging > QA > Dev), тем больше она должна походить на продакшен. Это позволяет выявлять environment-specific баги.
4. Автоматизация развертывания: Процесс деплоя во все среды, включая прод, должен быть одинаковым и автоматизированным (использование одних и тех же Ansible-плейбуков, Docker-образов, Helm-чартов).

Пример типичного пайплайна с использованием сред

Разработчик -> (Пишет код) -> Git -> CI Сервер -> [Сборка и юнит-тесты] -> Dev Среда
       |
       v
[Интеграционные тесты в CI] -> QA Среда -> (Ручное+Автотесты) -> Stage Среда -> (Финальный смоук, UAT)
       |
       v
(Успех) -> Продакшен Среда

Вывод: Нерелизные системы — это не просто "дополнительные сервера", а стратегическая инфраструктура, позволяющая контролировать качество, скорость и безопасность поставки ПО. Понимание их назначения, отличий и правил работы с ними — обязательная компетенция для QA-инженера, участвующего в построении процессов CI/CD.