Сколько вкладок открыто рядом с pull request?
Представьте, что в процессе onboarding для бесплатной пробной версии вашего продукта вы занялись новой issue: сделайте шаг “invite your teammates” необязательным. По мере роста числа регистраций команда поддержки продолжает отмечать этот шаг как точку трения. Быстрая победа, правда?
От определения объёма работ до deployment вам нужны ответы на следующие четыре вопроса:
Это действительно правильное изменение?
В порядке ли зависимости, которых я коснулся?
Как безопасно внедрить это изменение?
Безопасно ли сейчас выполнять deployment?
Ответ на каждый вопрос находится в отдельном инструменте, поэтому работа над pull request означает перенос одного и того же контекста между четырьмя разными местами.
Приложения-агенты GitHub предоставляют инструменты, необходимые для ответа на эти вопросы, прямо там, где вы уже работаете, используя ту же платформу и тот же harness, что и наш собственный Copilot cloud agent.
На следующем примере показано, как, не покидая GitHub, ответить на эти вопросы и использовать уже необходимые вам сервисы, такие как Amplitude, Endor Labs, LaunchDarkly и PagerDuty, чтобы выполнить этот запрос.
1. До начала разработки
Команда поддержки говорит, что шаг “invite your teammates” раздражает клиентов, которые проходят onboarding в вашем продукте, но не предоставила никакой информации о том, кто именно жаловался и приводили ли эти жалобы к потере клиентов. Ваш скептицизм вполне оправдан. Поэтому вместо того, чтобы открывать Amplitude и создавать запрос для проверки своей гипотезы, вы напрямую обращаетесь к агенту Amplitude на вкладке Agents:
@amplitude[agent] Связано ли завершение шага приглашения команды с успехом на последующих этапах воронки? Разбей по измеряемым нами сегментам.
Картина ясна: пользователи из команд, завершившие этот шаг, с большей вероятностью сохраняются впоследствии, тогда как для одиночных пользователей такой связи нет. Теперь есть основания пересмотреть охват: отложите этот шаг для зарегистрировавшихся в одиночку, а для команд сохраните его.
Доступ к информации о продукте теперь есть прямо внутри GitHub, поэтому направление можно скорректировать ещё до написания кода.
2. Во время разработки
Copilot открывает черновой pull request для внесения изменений. Приложение также обновляет зависимости, используемые в процессе onboarding. Вместо того чтобы ждать, пока позже не пройдёт CI-проверка, вы спрашиваете в комментарии агента Endor Labs:
@endor-labs-github-agenthq[agent] Есть ли что-то, на что мне следует обратить внимание в зависимостях, которых касается этот pull request?
Agent определяет изменённые зависимости, проверяет их на наличие известных уязвимостей и более широких рисков, связанных с пакетами, а затем представляет отчёт в pull request. На этот раз всё выглядит чисто. Ничего исправлять не нужно.
Проверка зависимостей превращается в проактивный контроль, пока изменения ещё находятся перед вами. Это гораздо лучше, чем исправлять проблемы после того, как CI-проверка завершилась с ошибкой.
3. Развёртывание
Предыдущее наблюдение теперь переносится в приложение: зарегистрировавшиеся в одиночку используют необязательный путь, а команды сохраняют текущий путь. Поскольку эти сегменты определяются во время регистрации, feature flag может напрямую нацеливаться на них. Как если бы вы попросили об этом коллегу по команде, попросите агента LaunchDarkly настроить это для вас:
@launchdarkly-agent[agent] пожалуйста, создай feature flag для этого pull request и подключи его к коду.
- key: defer-team-invite
- type: boolean
- default: false
- target: регистрации с намерением solo
- rollout: internal > 5% > 25% > 100%
Агент создаёт флаг в LaunchDarkly и добавляет реализацию в коде в виде commit, чтобы вы могли её проверить. Если целевая среда требует одобрения, вместо непосредственного применения изменения таргетинга он создаёт запрос на одобрение. Решение о том, следует ли продолжать развёртывание, по-прежнему принимает человек.
Настройка флага перестаёт быть процессом, требующим второго инструмента, ручного переноса кода и координации в Slack, и превращается в один комментарий к pull request и commit для вашей проверки.
4. Перед развёртыванием
Проверка подтверждает, что код корректен, однако вопрос о том, находится ли сервис в подходящем для развёртывания состоянии, — совсем другой.