Пример: тестовая инфраструктура для трёх принимающих
Вымышленный проект для иллюстрации гайда. Названия сред и инструменты условные.
Исходные условия
Команда развивает сервис обработки заявок. Три аналитика формулируют и принимают задачи. Агент должен одновременно работать над тремя задачами. Приложение взаимодействует с внешним справочником и сервисом уведомлений; в процессе есть таймер напоминания и закрытие просроченной заявки.
В этом примере подходящих сред для приёмки у команды нет, поэтому новые UAT создаются по образцу DEV. Выбранный состав: 3 DEV + 3 UAT — всего 6 независимых сред. Это не шесть отдельных серверов по обязательному правилу: способ размещения выбирается под инфраструктуру проекта.
Распределение сред
| Среда | Кто работает | Назначение и правило занятости |
|---|---|---|
| DEV-1 | Агенты | Задача A: новое поле заявки |
| DEV-2 | Агенты | Задача B: повторная попытка обращения к справочнику |
| DEV-3 | Агенты | Задача C: напоминание и закрытие просроченной заявки |
| UAT-1 | Аналитик Анна; агент по её запросам | Приёмка результата, выбранного Анной |
| UAT-2 | Аналитик Борис; агент по его запросам | Приёмка результата, выбранного Борисом |
| UAT-3 | Аналитик Вера; агент по её запросам | Приёмка результата, выбранного Верой |
В DEV люди подключаются только при проблеме, которую агенты не смогли решить. UAT закреплены за принимающими; после приёмки они могут использовать их для следующих задач. Ко всем трём UAT у агента есть доступ для разбора замечаний, независимо от исполнителя развёртывания.
Для задачи B процесс сборки публикует артефакт B-17 в хранилище. Агент выполняет деплой B-17 из хранилища в DEV-2 для проверки. Для приёмки Анной выполняется отдельный деплой того же B-17 из хранилища в UAT-1. Оба деплоя ссылаются на один неизменяемый идентификатор артефакта; каждый стенд получает свою конфигурацию и данные.
В этом примере используется параметризованный деплой. Если CI/CD клиента запускается только из фиксированных веток, допустим вариант со служебными деплойными ветками. Требования к изоляции сред и цепочке «ревизия → сборочный артефакт → деплой» остаются теми же.
Решение по архитектуре
| Компонент | Решение для примера | Что переиспользуем или создаём |
|---|---|---|
| Сборка и хранилище артефактов | Сборка по точной ревизии, публикация под неизменяемым идентификатором | Используем хранилище пакетов или контейнерных образов; настраиваем публикацию и связь с ревизией |
| Деплой приложения | Каждый стенд получает выбранный артефакт из хранилища и свою конфигурацию | Переиспользуем общий кластер; добавляем параметризованный деплой по идентификатору артефакта |
| Базы и миграции | Отдельная база на среду; миграции и сброс адресуются выбранной базе | Переиспользуем сервер БД при достаточных ресурсах; создаём независимые базы |
| Очереди и обработчики | Отдельные очереди и обработчики для среды | Расширяем существующие настройки и проверяем отсутствие перекрёстного потребления |
| Кэш и файлы | Изолированные ключи и хранилища; сброс только целевой среды | Переиспользуем инфраструктуру хранения с отдельными областями данных |
| Моки интеграций | По отдельному экземпляру сервиса моков на среду; каждый имитирует справочник и уведомления | Создаём один переиспользуемый пакет моков и развёртываем шесть экземпляров |
| Таймеры и бизнес-время | Управление таймерами процесса плюс виртуальные часы для расчёта срока заявки; настройки отдельны для среды | Создаём инструменты, поскольку исходное приложение зависит от реального времени |
| Данные и диагностика | Версионированные наборы, сброс, журналы и связь с ревизией приложения | Дорабатываем существующие средства подготовки данных |
В этом примере отдельные экземпляры моков выбраны потому, что существующий мок имеет глобальные настройки ошибок и общий журнал. Один физический сервис можно было бы оставить после добавления и подтверждения независимых контекстов для всех шести сред.
Смена задач и состояние БД
Вымышленный пример: задача A переименовала поле status в state. Следующая задача B основана на исходной версии и ещё использует status. Деплой артефакта B поверх оставшейся БД задачи A не даст работоспособную среду.
Для DEV-1 заполнена такая карточка:
| Поле | Значение в примере |
|---|---|
| Цель сброса | Только БД dev1_app и связанные состояния DEV-1 |
| Исходный комплект | base-v12: снимок со схемой и историей миграций V12; базовые данные D4. Ветки A и B начинались с V12 |
| Целевая ревизия | SHA задачи B; артефакт B-17 опубликован в хранилище |
| Порядок | Зарезервировать среду, сохранить доказательства A, остановить записи и фоновые задания; восстановить base-v12; применить изменения B; загрузить сценарный набор B-cases-v2; выполнить деплой B-17 из хранилища и проверки |
| Связанные состояния | Очистить очереди и кэш DEV-1, сбросить её моки и таймеры, установить начальное время набора B |
| Проверка | В схеме есть ожидаемый B столбец status, миграции A отсутствуют, данные и smoke соответствуют B; повтор процедуры даёт тот же результат |
| Изоляция | DEV-2, DEV-3 и занятые UAT продолжают работу; результаты проверки их состояния приложены к прогону |
В журнале сохраняются фактические версии и доказательства, а не только ссылка на эту инструкцию. Если B основана на другой истории, для неё выбирается другой совместимый комплект или создание БД с нуля. Снимок base-v12 не универсален.
Отдельно для A проверяется обновление БД V12 с существующими записями: после переименования значения статусов сохранены в state. Восстановление уже изменённой схемы такую проверку не заменяет.
Допустим, в начале PoC автоматических миграций ещё нет. Для изменения A агент готовит версионированный SQL-скрипт с проверками; назначенный разработчик выполняет его по запросу HITL и фиксирует результат. До продолжения агент проверяет фактическую схему и данные. Временный порядок содержит также восстановление при частичном выполнении.
| Пробел | Работа плана | Ответственный и срок в примере | Критерий результата |
|---|---|---|---|
| Изменения БД требуют ручного запуска | Внедрить автоматические миграции, перенести исходную схему и скрипты, подключить запуск к деплою | Разработчик клиента; конец фазы 2 PoC. В рабочем плане — имя и дата | Создание с нуля и обновление V12 с данными проходят; выполненные изменения повторно не применяются; сбой останавливает подготовку среды и фиксируется |
| Сброс и данные готовятся вручную | Подготовить команду восстановления по ID среды и версии набора | ИИ-инженер клиента; до типичных задач фазы 3 | Повторная подготовка даёт заданные схему и данные, соседняя среда не затронута |
Эти сроки иллюстрируют план, а не являются общим гейтом методологии. Если автоматизация продолжается на Пилоте, сохраняются проверенный временный порядок, выделенное время исполнителя и актуальный срок работ. Его участие и ожидание фиксируются в показателях.
Для занятой UAT тот же технический рецепт допустим только после разрешённого изменения состояния приёмки. При запрете сброса общего pre-prod команда использует другую среду или проверенное совместимое обновление.
Как выглядит параллельная работа
- В DEV-1 агент проверяет новое поле на обычных данных.
- Одновременно в DEV-2 мок справочника отвечает ошибкой на первые два вызова и успехом на третий. Агент проверяет повторные попытки и журнал запросов.
- В DEV-3 агент готовит заявку, продвигает её бизнес-время и запускает нужный таймер. Проверяет напоминание, переход статуса и отсутствие лишних уведомлений.
- В UAT-1 Анна продолжает приёмку ранее подготовленной версии. Изменения моков, времени и сбросы DEV не влияют на её среду.
Сначала проверяется согласованная последовательность управления бизнес-временем и таймерами. Простого изменения даты заявки недостаточно: должны выполниться предусмотренные обработчики и связанные проверки срока.
Деплой для приёмки: варианты
Развёртывание поручено агенту
Анна просит агента выполнить деплой артефакта B-17 из хранилища в UAT-1 и загрузить набор «Заявки для проверки справочника». Агент сообщает:
- Адрес UAT-1, идентификатор и ссылку на артефакт B-17 в хранилище, ревизию кода и запись деплоя.
- Версию набора данных и активный сценарий мока.
- Результат проверки готовности и ссылки на проверки артефакта B-17.
- Известные ограничения.
После начала приёмки агент не заменяет эту версию из-за появления нового результата. Анна может отдельно попросить включить отказ справочника, вернуть обычный ответ, загрузить демонстрационные данные или развернуть исправление. Каждая операция выполняется только в UAT-1 и фиксируется; при изменении результата указывается, что проверить повторно.
UAT-2 и UAT-3 продолжают работу независимо.
Принимающий развёртывает сам
Борис выбирает ревизию ветки задачи, запускает сборку и публикацию артефакта либо выбирает уже опубликованный артефакт нужной ревизии. Через привычный процесс команды выполняет его деплой из хранилища в UAT-2. Фиксирует идентификатор артефакта, ревизию и набор данных. Агент не обязан выполнять это развёртывание, но имеет доступ к UAT-2: при замечании Бориса она проверяет описанное поведение и получает необходимые журналы и контекст состояния. Развёртывание исправления снова выполняется выбранным Борисом и командой способом.
Если уже есть подходящий pre-prod
При наличии подходящего pre-prod команда могла бы проводить приёмку там и не создавать новые UAT для покрываемых им сценариев. Деплой опубликованного артефакта из хранилища выполнялся бы штатным процессом клиента; команда согласовала бы состав сборки, время приёмки и изменения среды. Обязательное условие сохранилось бы: агент имеет доступ к этой среде для разбора замечаний, даже если не может сам развёртывать или сбрасывать её.
План подготовки: пример заполнения
| Возможность | Исходное состояние | Работа | Ответственный | Когда нужна | Подтверждение |
|---|---|---|---|---|---|
| 3 DEV и 3 UAT | Есть один общий стенд | Подготовить шесть изолированных конфигураций и базы, правила занятости и развёртывание | Инженер инфраструктуры клиента | Первая DEV — до фазы 1 PoC; полный состав — до фазы 3 | Параллельные деплои артефактов из хранилища, сброс одной среды не меняет остальные |
| Доступ агента к каждой UAT | Доступ есть только у людей | Обеспечить доступ к фактической версии, поведению, журналам и необходимым данным; согласовать доступные операции | Владелец среды клиента | До приёмки | Агент разбирает замечание в UAT, развёрнутой Борисом самостоятельно |
| Сборка и деплой | Существующий процесс нужно проверить | Настроить публикацию артефактов и деплой из хранилища по идентификатору | Инженер инфраструктуры клиента | До первой задачи PoC | В каждой записи деплоя видны хранилище, артефакт и ревизия |
| Управляемые моки | Один мок с глобальным переключателем ошибок | Добавить программные сценарии, сброс и историю; развернуть по экземпляру на среду | Разработчик клиента с ИИ-инженером сопровождения | До задач с интеграциями | Одновременно успех в DEV-1 и ошибки с восстановлением в DEV-2 |
| Таймеры и виртуальное время | Проверки требуют реального ожидания | Добавить управление таймерами и согласованный источник бизнес-времени | Разработчик и архитектор клиента | До задачи C, не позднее фазы 3 PoC | Просрочка и напоминание воспроизводятся без ожидания; соседние среды не затронуты |
| Данные | Наборы загружаются вручную | Подготовить команды загрузки и восстановления по среде | Тестировщик и ИИ-инженер клиента | До зависимых сценариев и приёмки | Агент дважды воспроизводит сценарий из одинакового набора |
| Инструкции и диагностика | Знания у одного специалиста | Описать операции, ошибки, сбор журналов и обращение за помощью | ИИ-инженер сопровождения совместно с владельцем среды | При совместном освоении диагностики, до передачи этой работы клиенту | ИИ-инженер клиента выполняет подготовку по инструкции с согласованной помощью |
В рабочем плане вместо ролей указываются имена и календарные даты. Сроки выше показывают зависимости, а не универсальную оценку трудоёмкости.
Если инструменты времени не готовы, команда не объявляет задачу C проверенной. Её либо откладывают с обновлением плана, либо явно исключают из текущей области и сохраняют работу по созданию инструментов для последующего включения.
Что приложить к решению о готовности
- Реестр шести сред: адреса, назначение, владельцы, текущее использование и ссылки на управление.
- Карту изоляции данных, очередей, моков и времени.
- Результаты параллельного прогона, сброса и проверки независимости.
- Выбранный способ подготовки результата в каждой UAT, исполнителя развёртывания и пример передачи контекста приёмки.
- Подтверждённый доступ агента к каждой используемой UAT для диагностики замечаний.
- Оставшиеся ограничения и план их устранения.
Во время Пилота ожидание сред, сбои инструментов и действия по улучшению отражаются в еженедельном журнале.
Пример развития тестового набора
Допустим, на старте у команды нет поддерживаемых автотестов. Это не мешает первой задаче PoC: агент выполняет явные проверки, сохраняет временный скрипт и результаты. Далее команда закрепляет повторяющиеся сценарии по стратегии тестирования.
| Сценарий | Подходящая проверка | Где выполняется и как развивается |
|---|---|---|
| Правила нового поля заявки | Unit: валидация и граничные значения | Без стенда, в тестовом образе; сохраняется постоянная команда запуска |
| Сохранение нового поля | Интеграционная проверка реальной БД | Тестовый раннер и временная БД, без полного DEV; проверяются миграция и сохранённые данные |
| Создание заявки через API | API-автотест | На DEV с артефактом из хранилища, исходными данными и независимыми моками |
| Ввод и отображение поля | UI-автотест | Браузерный раннер и DEV; основной маршрут включается в регрессию |
| Повторные вызовы справочника | Проверка отказов через API; контрактная проверка взаимодействия отдельно | Мок задаёт последовательность ошибок и успеха; проверяются результат и число попыток. Совместимость контракта подтверждается доступной проверкой поставщика |
| Напоминание и просрочка | Unit для расчёта срока плюс интеграционный сценарий времени | Простые правила — без стенда; процесс с таймером — на DEV с управлением временем и наблюдением побочных эффектов |
| Готовность после деплоя | Smoke из коротких API/UI-сценариев | Запускается для конкретного артефакта; первые сохранённые скрипты превращаются в регулярный набор |
| Массовое создание заявок | Нагрузка, если это значимый риск | Отдельно планируются ресурсы, данные, профиль и критерии; это не условие старта PoC |
| Сбой экземпляра обработчика | Контролируемая проверка устойчивости, если нужна | В выделенном контуре проверяются сохранность заявок и восстановление; не затрагивается текущая приёмка |
В первую неделю PoC проходит онбординг: команды проверок и деплоя включаются в проектную литературу и проверяются на минимальном пути. Во вторую неделю закрепляются повторяемые проверки простых задач, в третью и четвёртую — выбранных целевых сценариев. Оставшиеся пробелы получают ответственных и сроки. На Пилоте команда еженедельно рассматривает, какие временные проверки повторяются и что следует добавить в поддерживаемый набор.
Это пример выбора проверок, а не требование дублировать каждый сценарий на всех уровнях.
Примеры механизмов для сложных сценариев
Это примеры для разных продуктов; эмуляторы оборудования и другие инструменты включаются в план только при наличии соответствующих задач.
| Сценарий | Подготовленный механизм | Как агент проверяет результат |
|---|---|---|
| Случайный выбор исполнителя | Отдельный генератор с seed и заданной последовательностью | Повторяет неуспешный выбор и принудительно проходит граничные варианты |
| Напоминание по сроку | Начальные часы, продвижение времени и запуск таймера | Проходит границу срока без ожидания; видит одно напоминание в тестовом приёмнике |
| Ошибка после отправки уведомления | Почтовый приёмник с API и сценарий повторной операции | Проверяет адресата, содержимое и отсутствие второго письма при повторе |
| Два одновременных изменения заявки | Барьер перед фиксацией изменений и журнал транзакций | Воспроизводит конфликт, проверяет результат по правилам продукта и отсутствие потерянного изменения |
| Чтение показания контроллера | Эмулятор протокола с профилем, командами и отключением | Подаёт показание, ошибку и восстановление; проверяет обмен без доступа к реальному устройству |
| Повтор команды после рестарта | Исходные данные, последовательность команд, остановка и восстановление процесса | Подтверждает сохранённое состояние и отсутствие повторного эффекта |
| Разные локали и feature flags | Два профиля в отдельных процессах | Получает ожидаемое поведение каждого профиля без переноса глобальных настроек |
В запись прогона входят выбранные параметры, версии, последовательности и ссылки на доказательства. Отсутствующий механизм получает работу в существующем плане подготовки; список сам по себе готовность не подтверждает.