В первой статье я заявил: подключение тестирования на новый проект — 4 часа. Звучало уверенно. Настало время раскрыть карты.

Привет! Это снова Михаил Федоров. В предыдущей статье я рассказал об архитектуре QA Assist — системе из 11 AI-агентов, которая берёт на себя 80% рутины QA-инженера. Среди метрик была строчка: «Подключение тестирования на новый проект — ~4 часа настройки, первые баги уже в бэклоге».

Красиво, правда? Прямо слайд для презентации. Давайте проверим эту цифру на реальном проекте — и посмотрим, насколько я был честен с вами (спойлер: не совсем).

Оглавление

  1. Контекст: проект и вводные

  2. Кто такой Сергей и что у него в арсенале

  3. Фаза подготовки: 5 шагов «за 4 часа»

    Шаг 1: Настройка проекта в QA Assist

    Шаг 2: Сборка Global Context

    Шаг 3: Подготовка доступов

    Шаг 4: Настройка внешних инструментов

    Шаг 5: Договорённости с командой

  4. Итого: куда делись 4 часа

  5. Заключение

1. Контекст: проект и вводные

Назовём проект условно «Платформа» (реальное название под NDA). Это заказная разработка — IT-решение для крупного клиента. Типичная картина:

  • Сроки горят

  • Бюджеты ограничены

  • Тестированием занимаются аналитики «в меру возможностей»

  • Есть опасения, что с качеством продукта будут проблемы

И вот однажды приходит запрос: «Есть команда, которая пилит продукт. Нужно усилить тестирование. Но нанимать выделенного QA на этот проект — долго и дорого. Что можно сделать?»

Собственно, мой выход. Предлагаю испытать на проекте QA Assist — AI-ассистента, о котором я рассказывал в первой статье. Команда, конечно, смотрит с любопытством и лёгким скепсисом. Но соглашаются — терять-то нечего.

Запускаю секундомер ⏱️. Четыре часа — вызов принят. Что может пойти не так?

2. Кто такой Сергей и что у него в арсенале

Чтобы понять стартовые условия, познакомимся с главным героем.

Сергей — сеньор QA-инженер из нашего центра компетенций. Он:

  • Предварительно изучил QA Assist, прошёл через пилот на другом проекте и знает все нюансы

  • Имеет подписку на Claude Pro (Opus) — обязательное условие для работы ассистента

  • Не погружён в проект «Платформа» — видит его впервые

  • Помимо «Платформы» ведёт текущие проекты

Важно: Сергей не будет месяц вникать в архитектуру, ходить на все стендапы и изучать каждый микросервис. Это принципиально другой подход — и об этом мы поговорим в разделе про договорённости с командой.

Итак, час пробил. Сергей открывает терминал.

3. Фаза подготовки: 5 шагов «за 4 часа»

Шаг 1: Настройка проекта в QA Assist

Ожидание: ~20 минут. Реальность: ну, давайте разбираться.

Казалось бы — создай один файл и готово. QA Assist использует каскадную систему конфигурации: на каждый проект заводится свой .env-профиль с настройками.

Что делает Сергей:

Создаёт файл .env.platform в корне проекта:

# .env.platform
JIRA_PROJECT_KEY=PLAT
API_TESTS_REPO_URL=https://gitlab.company.com/qa/platform-api-tests.git
UI_TESTS_REPO_URL=https://gitlab.company.com/qa/platform-ui-tests.git
ZEPHYR_PROJECT_NAME=Платформа

# Источники для автоматической сборки Global Context
GC_SOURCE_REPOS=https://gitlab.company.com/platform/backend.git,https://gitlab.company.com/platform/frontend.git
GC_SOURCE_API_URLS=https://platform.test.company.com
GC_SOURCE_CONFLUENCE=https://confluence.company.com/pages/viewpage.action?pageId=78901

Семь значимых строчек. Всё остальное — URL Jira, токены, настройки GitLab — берётся из базового .env, который уже настроен и одинаков для всех проектов.

Как работает каскад:

.env                          ← базовые credentials (Jira, GitLab, Figma)
  └── .env.platform           ← настройки проекта (repos, project key)
        └── .env.platform.mobile  ← переопределения для подпродукта (если нужно)

Каждый уровень переопределяет переменные предыдущего. Система автоматически определяет проект по ID задачи: видит PLAT-42 — загружает .env.platform. Никакого ручного переключения между проектами.

Если в Jira-проекте несколько продуктов (например, веб-платформа и мобильное приложение), можно настроить маршрутизацию по Epic через subprojects.yaml. Но для «Платформы» это пока не нужно — один проект, одна конфигурация.

Написать файл — действительно 20 минут. Но чтобы его написать, нужно знать, что в него вписать. А вот тут начинаются нюансы.

Где взять URL репозиториев для автотестов?

API_TESTS_REPO_URL и UI_TESTS_REPO_URL — это репозитории, куда ассистент будет складывать готовые автотесты. Если у команды их ещё нет — нужно создать. А создать репозиторий в корпоративном GitLab — это:

  • Выяснить, в какой группе заводить (у QA-отдела или у команды проекта?)

  • Получить права на создание репозиториев в этой группе (а их, конечно, нет)

  • Оформить заявку… подождать… получить… настроить

Где взять URL исходников для сборки контекста?

GC_SOURCE_REPOS — это репозитории самого продукта, которые ассистент будет анализировать. Сергей видит проект впервые. Ему нужно:

  • Узнать у команды, какие репозитории есть и где они лежат

  • Получить доступ на чтение к каждому из них (а у QA-инженера из другого подразделения его, конечно, нет)

  • То же самое с Confluence — нужно знать, где живёт документация, и иметь к ней доступ

В идеальном мире тимлид скинет список ссылок в чате за 5 минут. В реальном — Сергей пишет в общий канал, ждёт ответа, получает ссылку на одну репу из трёх, просит остальные, получает «спроси у Васи», пишет Васе…

⏱️ Таймер: 00:20 на сам файл. Но сбор информации для него — от получаса до пары дней. Что ж, бодрое начало.

Шаг 2: Сборка Global Context

Ожидание: ~30 минут. Реальность: ~30 минут… самой сборки.

Global Context — централизованное хранилище знаний о проекте, которое используют все 11 скиллов ассистента. Без него генерация тестов превращается в генерацию «правдоподобного мусора» — красивого, но бесполезного.

И вот тут начинается самое интересное. Контекст не собирается вручную. Для этого есть специальный скилл — global-context-builder.

Как работает сборка

Сергей пишет в терминале одну фразу:

собери контекст проекта PLAT

Дальше ассистент работает сам. Вот что происходит под капотом.

Фаза 1 — Инвентаризация источников. Скилл читает .env.platform и находит переменные GC_SOURCE_*:

  • GC_SOURCE_REPOS — репозитории GitLab для анализа кода

  • GC_SOURCE_API_URLS — живые URL для скачивания OpenAPI-спецификаций

  • GC_SOURCE_CONFLUENCE — страницы Confluence с бизнес-документацией

Если эти переменные не указаны — скилл перейдёт в интерактивный режим: найдёт репозитории через GitLab API, предложит варианты, спросит про дополнительные источники. Но мы уже прописали всё в .env.platform, так что скилл сразу показывает план:

Global Context Builder: PLAT
Mode: build

Источники:
  [P1] GitLab: platform/backend (Go), platform/frontend (React)
  [P2] Live API: https://platform.test.company.com (доступен)
  [P3] Confluence: 1 страница

Будет создано:
  P0: services_endpoints.yaml, test_data.yaml
  P1: PLAT_FULL_SPECIFICATION.md, PLAT_TECHNICAL_REQUIREMENTS.md, api_platform.yaml
  P2: web_platform.md

Продолжить?

Сергей подтверждает. Поехали.

Фаза 2 — Сбор из GitLab (приоритет 1). Скилл клонирует каждый репозиторий и методично извлекает из кода:

Что ищет

Куда складывает

API-контракты (OpenAPI, Swagger)

api_platform.yaml

Стек и архитектуру

PLAT_TECHNICAL_REQUIREMENTS.md

Модели данных, миграции

PLAT_TECHNICAL_REQUIREMENTS.md

URL окружений, креды из CI

services_endpoints.yaml, test_data.yaml

Бизнес-логику

PLAT_FULL_SPECIFICATION.md

Роутинг, формы, API-вызовы фронтенда

web_platform.md

Фаза 3 — Дополнительные источники. Параллельно скилл:

  • Скачивает OpenAPI-спецификацию с живого API (приоритет 2) — и сверяет с тем, что нашёл в коде

  • Загружает страницы Confluence через скилл jira-fetch (приоритет 3) — извлекает бизнес-контекст: роли, процессы, юзкейсы

Правило разрешения конфликтов простое: требования побеждают. Если в Jira написано POST /users, а в коде GET /users — доверяем требованиям. Код — это реализация, которая может содержать ошибку. А вот для структуры контекста (какие сервисы есть, какие эндпоинты доступны, какой стек) скилл опирается на код — здесь он источник факта.

Фаза 4 — Анализ и дедупликация. Скилл проверяет:

  • Каждый API-эндпоинт реально существует в текущем коде или swagger

  • Каждый сервис отвечает на /health

  • Каждая переменная окружения есть в актуальном конфиге

Фаза 5 — Генерация файлов. На выходе — структурированная директория:

testing/jira/Global-context/PLAT/
├── services_endpoints.yaml            # P0: карта сервисов и URL по окружениям
├── test_data.yaml                     # P0: тестовые пользователи, креды, данные
├── PLAT_FULL_SPECIFICATION.md         # P1: бизнес-логика, роли, процессы
├── PLAT_TECHNICAL_REQUIREMENTS.md     # P1: архитектура, стек, БД, интеграции
├── api_platform.yaml                  # P1: OpenAPI-спецификация
└── web_platform.md                    # P2: роутинг, формы, API-вызовы фронтенда

Каждый файл генерируется по строгому шаблону с фиксированной структурой разделов. Например, FULL_SPECIFICATION всегда содержит: назначение системы, роли участников, бизнес-процессы, ключевые сущности, интеграции, глоссарий. TECHNICAL_REQUIREMENTS — компоненты системы, инфраструктура, авторизация, базы данных, межсервисное взаимодействие. Никакой «свободной формы» — информация раскладывается по полочкам.

Это работает в обе стороны. Ассистенту проще находить нужные данные, когда они лежат в предсказуемом месте. Но и Сергею — тоже. Он впервые видит проект «Платформа», и через 30 минут после запуска скилла у него на руках структурированное досье: какие сервисы есть, как они общаются между собой, какие роли в системе, какие эндпоинты доступны, где какие данные. Фактически Global Context становится онбордингом в проект — только вместо двух недель он занимает полчаса.

К каждому файлу добавляются обязательные метаданные — откуда взята информация, когда создано, когда обновлено. Перед любым изменением скилл автоматически делает git-снапшот, чтобы можно было откатиться.

Приоритеты файлов

Не все файлы одинаково важны. Система использует чёткую иерархию:

Приоритет

Файлы

Значение

P0 (обязательно)

services_endpoints.yaml, test_data.yaml

Без них автотесты не запустятся

P1 (важно)

Спецификация, техтребования, OpenAPI

Качество сценариев зависит от них

P2 (полезно)

Описание фронтенда

Улучшает UI-тесты

P3 (авто)

actual_features.md

Генерируется автоматически, руками не трогать

Бонус: actual_features.md. Если у проекта уже есть тестовая модель в Zephyr Scale (тест-кейсы, сценарии), то отдельный скилл global-context-updater проанализирует все существующие кейсы и сгенерирует файл, описывающий актуальное ожидаемое поведение системы — что она делает, как реагирует на разные входные данные, какие ограничения имеет. По сути, это спецификация, восстановленная из тестов. Для нового проекта этого файла ещё нет, но по мере наполнения тестовой модели он появится и станет ещё одним источником знаний для ассистента.

А что дальше с контекстом?

Global Context — живой организм. Скилл поддерживает четыре режима:

  • build — первоначальная сборка с нуля (то, что мы только что сделали)

  • update — добавление новой информации. Показывает diff, спрашивает по каждому изменению: «Найден новый эндпоинт POST /api/v1/reports/export. Добавить?»

  • cleanup — проверка актуальности. Удаляет устаревшие эндпоинты, невалидные URL

  • rollback — откат к любому предыдущему снапшоту

Файл test_data.yaml работает по принципу append only — данные только добавляются, никогда не удаляются. Даже если что-то кажется устаревшим — максимум помечается комментарием # deprecated. Это страховка: лучше лишняя строчка в конфиге, чем упавший тест из-за удалённого пользователя.

Из практики: первая сборка даёт ~70–80% нужного контекста. Остальное дособирается в процессе работы — при первом запуске сценариев скилл scenario-data-fix автоматически найдёт пробелы в test_data.yaml и предложит их заполнить.

⏱️ Таймер: 00:50. Вроде неплохо. Но секундочку…

Шаг 3: Подготовка доступов

Ожидание: ~15 минут. Реальность: от 15 минут до… ну, вы поняли.

Вот тут наш таймер начинает нервно тикать. Технически проверить доступы — дело пяти минут. Сергей проходится по списку: Jira, GitLab, Zephyr Scale, Confluence, тестовый стенд — всё отвечает?

Всё ответило? Прекрасно, 15 минут.

Не ответило? Добро пожаловать в корпоративную реальность. Заявка на доступ в Jira — через ServiceDesk, согласование у руководителя проекта, ожидание 1–3 рабочих дня. GitLab — аналогично. Тестовый стенд — отдельная песня, потому что «а вы из какого отдела?» и «а зачем вам доступ к тестовым данным?».

А ещё запрос может вообще не дойти до сервера. Потому что тестовый стенд — во внутренней сети, а Сергей работает удалённо. Значит, нужен VPN. А VPN — это заявка, согласование, установка клиента, выдача сертификата. Отдельный квест в лучших традициях корпоративного IT.

Сергею нужно:

Система

Что нужно

Зачем

VPN

Подключение к корпоративной сети

Доступ до тестовых стендов и внутренних сервисов

Jira

Аккаунт с правами на чтение задач проекта PLAT

Загрузка требований, создание дефектов

GitLab

Personal Access Token (scopes: api, read_repository, write_repository)

Клонирование репозиториев, создание MR

Zephyr Scale

API-токен (обычно тот же, что для Jira)

Загрузка тест-кейсов в TMS

Тестовый стенд

Тестовые учётные записи с разными ролями

Запуск автотестов, сбор UI-селекторов

БД (ODBC)

Доступ к порту базы данных тестового окружения

Подготовка тестовых данных, проверка состояния после тестов

Последний пункт — отдельная боль. Доступ до базы — это не просто «дайте пароль». Это открытие сетевого порта через firewall, настройка ODBC-подключения, иногда — отдельная read-only реплика для QA, чтобы не положить тестовый стенд неосторожным запросом. DevOps скажут «заведите тикет», безопасники скажут «обоснуйте необходимость», DBA скажет «только read-only и через бастион-хост». К этому моменту Сергей уже забыл, зачем ему вообще нужна база.

⏱️ Таймер: 01:05… если повезло. Если нет — ставим на паузу и идём за кофе. Ожидание доступов — процесс небыстрый, кофе понадобится много.

Шаг 4: Настройка внешних инструментов

Ожидание: ~30 минут. Реальность: ~30 минут… если не считать ожидание прав.

Ассистент интегрируется с существующими инструментами команды. Некоторые из них нужно подготовить.

Zephyr Scale

  • Создать корневую папку проекта (например, «Платформа») — в ней ассистент будет создавать подпапки по сервисам. Он генерирует трёхуровневую иерархию автоматически: /Платформа/Auth/Авторизация пользователя

  • Настроить кастомные поля — приоритеты, метки manual/automated, статусы

  • Проверить права токена — создание и редактирование тест-кейсов, управление папками

Важно: договоритесь о структуре папок заранее. Если команда привыкла к своей иерархии, а ассистент нагенерирует другую — потом кто-то будет грустно перетаскивать 200 кейсов мышкой.

GitLab

  • Создать репозиторий platform-api-tests — сюда будут приходить MR с API-тестами

  • Создать репозиторий platform-ui-tests — сюда пойдут UI-тесты

  • Настроить базовую структуру: conftest.py, pytest.ini, requirements.txt, config.yaml

Если у команды уже есть репозитории с автотестами — ещё лучше. Ассистент при первом запуске читает conftest.py, helpers.py и другие общие файлы, чтобы переиспользовать существующие фикстуры и хелперы, а не плодить дубли.

CI/CD (опционально на старте)

  • Настроить пайплайн для запуска автотестов

  • Прописать переменные окружения (BASE_URL, креды) в CI/CD-настройках

Можно сделать и позже — ассистент запускает тесты локально на этапе отладки. Но к моменту первого MR пайплайн лучше уже иметь.

Figma (если есть макеты)

  • Убедиться, что Figma MCP-сервер подключён к Claude Code

  • Проверить доступ к макетам проекта

Ассистент через MCP-протокол извлекает из Figma структуру компонентов, текстовые значения и состояния элементов. Это значительно повышает качество UI-сценариев.

⏱️ Таймер: 01:35. Вроде укладываемся… ах да, нам ещё с людьми поговорить.

Шаг 5: Договорённости с командой

Ожидание: ~1 час. Реальность: ~1 час… но найти этот час в календарях четырёх человек — отдельный квест.

Это не технический, а организационный шаг. И, пожалуй, самый недооценённый. Без чётких договорённостей даже идеально настроенный ассистент принесёт больше хаоса, чем пользы.

Почему нужен особый формат работы

Сергей — не классический тестировщик на проекте. Он работает с несколькими проектами одновременно, усиленный AI-ассистентом. Это принципиально другой формат:

  • Сергей не ходит на все стендапы и планирования — только на ключевые сессии, связанные с тестированием

  • Сергей не расследует причины багов — он находит и описывает дефект, а команда устанавливает причину и чинит

  • Сергей не погружается глубоко в каждый микросервис — вместо этого использует Global Context и документацию

Если тестировщик будет погружаться в каждый проект «как положено» — ходить на все встречи, изучать весь код, расследовать все проблемы — его не хватит даже на один проект. А с ассистентом он покрывает несколько.

О чём договориться

Вот конкретный пример договорённостей, которые Сергей фиксирует с командой «Платформы»:

1. Флоу работы с задачами

Аналитик → оформляет требования в Jira → Сергей запускает ассистента →
→ Сценарии + автотесты → ревью → MR в репозиторий

  • Сергей берёт задачу в работу, когда она в статусе «Ready for QA» (или аналог)

  • Если требования неполные — Сергей возвращает задачу аналитику с конкретными вопросами, сформулированными ассистентом (скилл requirements-decomposer автоматически находит пробелы)

2. Ревью артефактов

Артефакт

Кто ревьюит

Когда

Декомпозиция требований (US/Tasks)

Аналитик

После генерации, до сценариев

Тестовые сценарии

Аналитик + тимлид

После генерации, до автоматизации

Автотесты (MR)

Разработчик

Стандартный code review

Тест-кейсы в Zephyr

Сергей

Финальная проверка перед загрузкой

Важный момент: ревью декомпозиции — это не формальность. Если аналитик скажет «тут всё не так», лучше узнать это до генерации 50 тест-кейсов, а не после.

3. Работа с дефектами

Здесь Сергей почти не участвует руками — за него работает цепочка скиллов:

  • На этапах генерации сценариев и автоматизации скиллы сами фиксируют расхождения между требованиями и реальным поведением системы — всё записывается в протокол ERRORS_DISCREPANCIES.md

  • Скилл discrepancies-fix анализирует каждое расхождение и классифицирует: очевидные случаи (текст в Figma отличается от требований, коды ответов в рамках одного класса) закрывает автоматически по иерархии приоритетов источников

  • Если расхождение похоже на баг — скилл уведомляет Сергея, показывает описание, шаги воспроизведения, ожидаемое и фактическое поведение. После подтверждения — автоматически создаёт дефект в Jira с баг-репортом, скриншотами и логами, и маркирует затронутые автотесты как xfail с привязкой к тикету

  • Сергей не расследует причину — это задача разработчика. Сергей только подтверждает: «да, это баг — заводи»

  • Когда баг исправлен — снимается xfail, тесты начинают проходить

4. Взаимодействие с аналитиком

  • Аналитик — основной контакт Сергея на проекте

  • Аналитик отвечает на вопросы по бизнес-логике, которые всплыли при декомпозиции

  • Аналитик проверяет, что сгенерированные сценарии соответствуют замыслу (не только букве требований)

  • Если ассистент нашёл противоречие между требованиями и реализацией — Сергей передаёт его аналитику для классификации: это баг или «так задумано»

5. Коммуникации

  • Общий канал в мессенджере для оперативных вопросов

  • Еженедельный статус по тестированию (краткий, 5 минут)

  • Расписание обновлений тестового стенда — чтобы не гонять тесты во время деплоя

Зачем фиксировать письменно

Эти договорённости Сергей оформляет в виде короткого документа (полстраницы) и отправляет тимлиду. Это не бюрократия — это страховка от «а мы так не договаривались». Через неделю никто не вспомнит, о чём говорили на созвоне. А документ — вспомнит.

⏱️ Таймер: 02:35. Ого, у нас ещё полтора часа в запасе! Мы что, реально укладываемся?

4. Итого: куда делись 4 часа

Давайте честно посмотрим на цифры.

Чистое техническое время

Шаг

Время

Что получили

Настройка проекта

~20 мин

.env.platform, проект готов к работе

Сборка Global Context

~30 мин

6 файлов с контекстом, собранных из кода, API и документации

Проверка доступов

~15 мин

Все системы отвечают, токены работают

Настройка инструментов

~30 мин

Zephyr, GitLab-репозитории, CI/CD

Договорённости с командой

~60 мин

Зафиксированный формат работы

Итого чистого времени

~2.5 ч

Проект полностью готов

Подождите-ка. Два с половиной часа? Это даже меньше четырёх! Получается, я занизил оценку? Можно было написать «2.5 часа» и выглядеть ещё эффектнее?

Ну… нет. Потому что вот настоящий таймлайн:

Реальное время (с учётом жизни)

Шаг

Чистое время

Реальное время

Почему

Настройка проекта

20 мин

2–8 часов

Сам файл — 20 минут. Но сначала: «Где ваши репы?», «А у меня нет доступа к Confluence», создание репозиториев для автотестов

Сборка Global Context

30 мин

30 мин

Скилл работает быстро — если доступы к репозиториям и Confluence уже есть

Подготовка доступов

15 мин

1–3 дня

ServiceDesk, VPN, согласования, «а вы точно из нашего отдела?»

Настройка инструментов

30 мин

2–4 часа

«У кого права на создание папок в Zephyr?», «Нужно согласовать с архитектором»

Договорённости с командой

60 мин

1–2 дня

Попробуйте собрать тимлида, аналитика и двух разработчиков в одно время

Итого

~2.5 ч

3–7 дней

Добро пожаловать в корпорацию

Вот так красивые «4 часа» превращаются в реальную неделю. Не потому что технология медленная — она-то как раз быстрая. А потому что:

  • Доступы пронизывают всё — они нужны не только на шаге 3, а буквально на каждом этапе. Чтобы написать .env-файл, нужно знать URL репозиториев — а чтобы их узнать, нужен доступ к GitLab-группе проекта. Чтобы запустить сборку контекста — нужен доступ к репам с исходниками и к Confluence. Чтобы создать репозитории для автотестов — нужны права в нужной группе. Доступы — это не один шаг, это фоновый процесс, который тормозит всё остальное

  • Люди заняты — созвон на час нужно вписать в календари пяти человек, у которых и без вас спринт горит

  • Информация распределена — ни один человек в команде не знает всё. URL репозиториев — у DevOps, страницы Confluence — у аналитика, тестовые учётки — у QA (которого, напоминаю, на проекте нет), стенды — у разработчика

Что можно ускорить

Хорошая новость: большая часть этого «ожидания» — не блокер. Сергей запускает процессы параллельно:

  • День 1: отправляет заявки на доступы + собирает контекст + договаривается о созвоне

  • День 2: получает часть доступов, настраивает инструменты, проводит созвон с командой

  • День 3: получает последние доступы, проверяет всё, запускает первую задачу

Если в вашей компании уже настроены процессы быстрой выдачи доступов (Single Sign-On, единый ServiceDesk, выделенный DevOps) — реально уложиться в один день. Если нет — закладывайте неделю и не расстраивайтесь.

Заключение

Так возможно ли запустить AI-тестирование за 4 часа?

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

Нет — если считать календарное время. Потому что между «я знаю, что нужно сделать» и «у меня есть все доступы и мы со всеми договорились» лежит корпоративная реальность. И это нормально.

Ключевой вывод: бутылочное горлышко — не технология, а организация. Скилл global-context-builder за полчаса проанализирует три репозитория, скачает OpenAPI-спецификацию, загрузит страницы Confluence и сгенерирует шесть структурированных файлов. А вот получить доступ к этим репозиториям — может занять три дня.

Следующую часть планирую написать через несколько месяцев работы на проекте — когда накопится достаточно материала. Постараюсь собрать метрики, аналитику, интересные случаи из практики и, конечно, сложности. Вот в последнем я точно не сомневаюсь — их будет предостаточно.

Если дочитали до сюда - ставлю вам лайк! Если вам интересно что будет дальше - поделитесь лайком и вы!

Ссылки: