Quantas abas estão abertas ao lado do pull request?
Imagine que você esteja lidando com uma nova issue no fluxo de onboarding da avaliação gratuita do seu produto: tornar a etapa “invite your teammates” opcional. À medida que os cadastros aumentam, a equipe de suporte continua apontando essa etapa como um ponto de atrito. Um ganho rápido, certo?
Do escopo ao deployment, você precisa das respostas para estas quatro perguntas:
Esta é realmente a mudança certa?
As dependências que alterei estão limpas?
Como faço para disponibilizar isso com segurança?
É seguro fazer o deployment agora?
Cada resposta está em uma ferramenta diferente; portanto, trabalhar no pull request significa transportar o mesmo contexto entre quatro lugares diferentes.
Os aplicativos de agentes do GitHub trazem as ferramentas de que você precisa para responder a essas perguntas para o lugar onde você já trabalha — e fazem isso na mesma plataforma e no mesmo harness do nosso próprio Copilot cloud agent.
O exemplo a seguir mostra como usar serviços dos quais você já depende, como Amplitude, Endor Labs, LaunchDarkly e PagerDuty, para responder a essas perguntas e concluir essa solicitação sem sair do GitHub.
1. Antes de começar o desenvolvimento
A equipe de suporte diz que a etapa “invite your teammates” é incômoda para os clientes que entram no processo de onboarding do seu produto, mas não forneceu nenhuma informação sobre quem está reclamando ou se essas reclamações estão levando à perda de clientes. É razoável manter o ceticismo. Por isso, em vez de abrir o Amplitude e criar uma consulta para validar sua hipótese, você pergunta diretamente ao agente do Amplitude na aba Agents:
@amplitude[agent] A conclusão da etapa de convite da equipe está relacionada ao sucesso nas etapas posteriores do funil? Faça a divisão de acordo com os segmentos que medimos.
A distinção é clara: os usuários de equipes que concluem a etapa têm maior probabilidade de serem retidos posteriormente, enquanto não há essa relação para usuários individuais. Agora há uma justificativa para redefinir o escopo: adie essa etapa para quem se cadastra individualmente e mantenha-a para as equipes.
O acesso aos insights de produto agora está dentro do GitHub, permitindo corrigir o rumo antes que qualquer código seja escrito.
2. Durante o desenvolvimento
O Copilot abre um rascunho de pull request para a alteração. A implementação também atualiza as dependências usadas no fluxo de onboarding. Em vez de esperar que uma verificação de CI falhe mais tarde, você pergunta ao agente da Endor Labs em um comentário:
@endor-labs-github-agenthq[agent] Há algo nas dependências afetadas por este pull request a que eu deva prestar atenção?
O agente identifica as dependências alteradas, verifica vulnerabilidades conhecidas e riscos mais abrangentes relacionados aos pacotes e, em seguida, apresenta um relatório no pull request. Desta vez, tudo parece estar em ordem. Não há nada que precise ser corrigido.
A análise de dependências se transforma em uma verificação proativa enquanto a alteração ainda está diante de você. Muito melhor do que fazer correções depois que uma verificação de CI falha.
3. Lançamento
A descoberta anterior agora é aplicada: quem se cadastra individualmente usa o caminho opcional, enquanto as equipes mantêm o caminho atual. Como esses segmentos são identificados durante o cadastro, uma feature flag pode direcioná-los diretamente. Como se estivesse pedindo a um colega de equipe, peça ao agente da LaunchDarkly que configure isso para você:
@launchdarkly-agent[agent] por favor, crie uma feature flag para este pull request e integre-a ao código.
– key: defer-team-invite
– type: boolean
– default: false
– target: inscrições com intenção solo
– rollout: internal > 5% > 25% > 100%
O agente cria a flag no LaunchDarkly e a adiciona como um commit para que você possa revisar a implementação no código. Se o ambiente de destino exigir aprovação, ele cria uma solicitação de aprovação em vez de aplicar diretamente a alteração de segmentação. A decisão sobre prosseguir ou não com o lançamento continua sendo de uma pessoa.
A configuração da flag deixa de ser um processo que exige uma segunda ferramenta, uma transferência manual de código e coordenação no Slack e passa a ser um único comentário em um pull request e um commit para sua revisão.
4. Antes do lançamento
A revisão indica que o código está correto; mas saber se o serviço está em boas condições para uma implantação é uma questão diferente.