As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Revisões do código de prontidão de lançamento
As revisões de código de prontidão para lançamento avaliam suas alterações de código quanto a riscos de dependência entre repositórios, conformidade com padrões internos e correção do controle de acesso. Ele também realiza testes de verificação automatizados — ele cria, executa e testa suas alterações de código — em um ambiente de verificação gerenciado pelo AWS DevOps Agente.
Introdução
Para usar as revisões do código de preparação para lançamento, conclua as seguintes etapas de configuração.
Etapa 1: habilite os recursos em seus repositórios
Os recursos de revisão de código e teste automatizado devem ser habilitados em seus repositórios conectados GitHub ou em seus GitLab repositórios antes que possam ser acionados.
A seção Revisão de código e teste automatizado nas configurações de integração do provedor de pipeline fornece dois recursos por repositório:
Análise automática de alterações por gatilho — Quando ativado, o DevOps Agente executa automaticamente uma revisão do código de prontidão de lançamento sempre que uma pull request ou uma solicitação de mesclagem é aberta ou atualizada. Os resultados da revisão aparecem como comentários em linha sobre o. PR/MR
Teste de verificação automatizado — Quando ativado, o DevOps Agente cria, executa e testa suas alterações de código em um ambiente de verificação gerenciado durante as revisões de código. Isso fornece validação funcional além da análise estática. Para obter mais informações, consulte Teste de verificação automatizado.
Você pode ativar ou desativar cada recurso de forma independente por repositório, permitindo que você use revisões de alterações sem testes de verificação ou vice-versa.
A seção também inclui:
Função de tempo de execução (opcional) — Escolha a função do IAM que o DevOps agente assume para executar recursos automatizados nos repositórios selecionados. Essa função é usada ao acessar serviços internos durante compilações, como registros de pacotes privados ou armazenamentos de artefatos. Para obter mais informações, consulte Etapa 2.
Para GitHub: Navegue até a seção Revisão de código e testes automatizados em suas configurações de GitHub integração e ative os recursos para cada repositório. Ambos os recursos são habilitados por padrão quando você conecta repositórios. Para obter instruções detalhadas, consulte Configurando a revisão de código e o teste automatizado.
Para GitLab: Navegue até a seção Revisão de código e testes automatizados em suas configurações de GitLab integração e ative os recursos para seus projetos. Para obter instruções detalhadas, consulte Configurando a revisão de código e o teste automatizado.
Etapa 2: configurar o acesso privado à VPC para o ambiente de teste de verificação (opcional)
As revisões de código de prontidão para lançamento podem realizar testes de verificação automatizados criando, executando e testando suas alterações de código em um ambiente de verificação (consulte Teste de verificação automatizado). Se seu processo de criação de código exigir artefatos de sistemas internos, como repositórios de imagens privados (por exemplo, Artifactory, Docker Hub Enterprise), armazenamentos internos de artefatos de construção ou repositórios de código dependentes, você precisará dar ao ambiente de teste de verificação acesso a uma VPC que possa alcançar esses endpoints de serviço.
Por padrão, o ambiente de teste de verificação não tem acesso de rede aos seus sistemas internos. Para habilitar o acesso, crie uma conexão privada e associe-a ao seu provedor de pipeline (GitHubou GitLab). O ambiente de teste de verificação usa a VPC associada a essa conexão privada criando e gerenciando uma ENI dentro da VPC, dando à rede do ambiente de construção acesso aos seus serviços internos.
nota
A integração com VPCs em sua conta direciona o tráfego de rede por meio de suas rotas internas, seguindo as restrições de rede em vigor.
Para configurar o acesso privado à VPC para testes de verificação:
Crie uma conexão privada voltada para a VPC em que seus serviços de compilação internos podem ser acessados. Para instruções, consulte Conectando-se a ferramentas hospedadas de forma privada.
Abra o console do AWS DevOps Agente e navegue até seu Espaço do Agente.
Acesse a guia Capacidades e selecione seu provedor de funil (GitHub ou GitLab).
Na seção Revisão de código e testes automatizados, associe a conexão privada ao seu provedor de pipeline selecionando-a nas conexões disponíveis.
Para a função Runtime, selecione uma função do IAM que o DevOps Agente assumirá ao acessar serviços internos durante as compilações. Essa função deve ter permissão para acessar o AWS Secrets Manager na mesma AWS conta do seu Agent Space. Recomendamos usar uma função diferente da sua função principal de agente.
Escolha Salvar para aplicar sua configuração.
Uma vez associado, o ambiente de teste de verificação provisionará um ENI na VPC da conexão privada, dando a ela acesso direto à rede aos seus serviços internos durante as compilações de revisão de código.
Realizando uma revisão de código
Você pode solicitar uma revisão de código sob demanda por meio do chat do DevOps agente:
“Revise a filial feature/payments do serviço de pagamento por recompra para verificar os riscos de liberação”
“Analise o commit abc123 na infraestrutura de repositório para ver se está pronto para o lançamento”
“Quais riscos de lançamento existem nas últimas mudanças no serviço de pedidos de recompra?”
O agente avalia o escopo especificado — uma ramificação, confirmação ou conjunto de alterações — e retorna um relatório de preparação para o lançamento. O relatório inclui:
Ação recomendada — BLOQUEAR, prosseguir com cuidado ou liberar com segurança
Resumo das mudanças — O que foi modificado e o escopo do impacto
Análise de risco — descobertas específicas com localizações de código afetadas
Recomendações — Etapas acionáveis para resolver cada descoberta
As revisões geralmente são concluídas em 8 a 10 minutos, dependendo do tamanho e da complexidade da alteração.
Revisões automatizadas de código
As revisões automatizadas de código são executadas sem intervenção manual. Eles podem ser acionados em dois contextos:
Revisões de código durante a geração de código
Ao usar o plug-in Kiro Power ou Claude Code, o agente de codificação pode invocar uma revisão de prontidão de lançamento à medida que o código é gerado. A análise avalia as mudanças em andamento em relação às suas políticas e dependências, apresentando as descobertas diretamente no IDE antes que o código seja confirmado.
Se forem encontrados problemas, o agente de codificação é notificado e pode resolvê-los imediatamente — corrigindo violações de políticas, corrigindo políticas de IAM com excesso de permissão ou preparando alterações dependentes em outros repositórios.
Revisões de código em pull requests e solicitações de mesclagem
Quando as PR/MR revisões automatizadas estão ativadas, o agente analisa cada nova solicitação de pull e solicitação de mesclagem em seus repositórios conectados. As avaliações são acionadas quando:
Um novo PR/MR é aberto
Novos commits são enviados para um existente PR/MR
As descobertas aparecem como comentários embutidos nas linhas de código afetadas, com a avaliação geral publicada como um PR/MR comentário. Você pode configurar se as descobertas bloqueiam mesclagens (verificação de status obrigatória) ou são apenas consultivas.
Limitação do repositório público
Os gatilhos automatizados de revisão de PR/MR código estão disponíveis somente para repositórios privados. DevOps O agente não revisa automaticamente os pull requests nem mescla solicitações em repositórios públicos.
Como qualquer pessoa pode abrir uma pull request em um repositório público, incluindo colaboradores externos desconhecidos, acionar automaticamente as avaliações desses PRs pode consumir recursos sem o conhecimento do proprietário do repositório ou processar conteúdo não confiável. Restringir gatilhos automatizados a repositórios privados garante que somente colaboradores confiáveis iniciem o fluxo de trabalho de revisão.
Se você usa um repositório público, ainda pode executar análises de código de prontidão para lançamento solicitando-as por meio do bate-papo do DevOps agente ou por meio de integrações de agentes de codificação (Kiro Power, plug-in Claude Code ou Transform custom). AWS
Teste de verificação automatizado
Quando uma avaliação de risco de prontidão de lançamento é acionada, o DevOps Agente cria um ambiente de verificação AWS gerenciado e clona seu código nele. O ambiente é executado com recursos de computação dedicados com restrições de rede que limitam o acesso a serviços confiáveis para construção, armazenamento de artefatos e recuperação.
DevOps O agente lê o código e os arquivos do projeto do seu aplicativo para determinar as ferramentas de construção e as dependências necessárias e, em seguida, as instala no ambiente de verificação. Depois de criar seu aplicativo com sucesso, o agente gera um plano de teste e o executa para identificar riscos funcionais, como casos extremos que podem resultar em falhas ou comportamento inesperado.
As descobertas dos testes de verificação estão incluídas no relatório final de preparação da versão, juntamente com as descobertas sobre padrões, dependência e controle de acesso.
Você pode usar Instruções do agente (AGENTS.md) para ajustar como o teste de verificação é realizado — por exemplo, especificar quais comandos de teste devem ser executados, o que constitui uma compilação aprovada ou quais partes do aplicativo devem ser exercidas durante a verificação.
Destinos de rede permitidos
O ambiente de teste de verificação tem acesso à rede de saída restrito a uma lista de permissões predefinida. Seu aplicativo pode acessar os seguintes domínios durante a validação:
| Domínio | Finalidade |
|---|---|
.amazonaws.com, .aws.amazon.com |
AWS serviços |
.public.ecr.aws |
Amazon ECR Public |
.docker.com, .docker.io |
Docker Hub |
.github.com, .githubusercontent.com |
GitHub |
.gitlab.com |
GitLab |
.npmjs.com, .npmjs.org |
registro npm |
.pypi.org, .pypi.python.org, .pythonhosted.org |
Python Package Index |
.crates.io, .rustup.rs |
Pacotes de ferrugem |
.maven.org, .gradle.org |
Java/Gradle pacotes |
.nuget.org |
Pacotes.NET |
.rubygems.org, .ruby-lang.org |
Pacotes Ruby |
.golang.org, .pkg.go.dev, .goproxy.io |
Pacotes Go |
.nodejs.org, .yarnpkg.com |
Node.js |
.alpinelinux.org, .debian.org, .ubuntu.com, .centos.org, .fedoraproject.org |
Repositórios de distribuição Linux |
.cloudfront.net |
CloudFront distribuições |
.google.com, .googleapis.com |
APIs do Google |
.microsoft.com, .visualstudio.com |
Serviços da Microsoft |
.sourceforge.net, .bitbucket.org |
Hospedagem fonte |
.prisma.sh |
Prisma ORM |
get.helm.sh |
Gerenciador de pacotes Helm |
.terraform.io |
Registro do Terraform |
buf.build |
Buf (Protobuf) |
.jitpack.io |
JitPack (Pacotes JVM) |
.scala-sbt.org |
Scala SBT |
.sheetjs.com |
SheetJS |
.confluent.io |
Confluente (Kafka) |
.external-secrets.io |
Operador de segredos externos |
registry.npmmirror.com |
registro de espelhos npm |
nota
Se seu aplicativo exigir acesso de rede a domínios que não estão nesta lista, você pode conectar seu ambiente de teste de verificação a uma VPC para fazer com que o agente use suas próprias configurações de firewall de rede, permitindo que você configure o acesso a qualquer um dos serviços que seu aplicativo exige.
Analisando os resultados da revisão de código
Cada revisão de código produz um relatório acessível na página de lançamentos do aplicativo web DevOps Agent. Os relatórios incluem:
Encontrando categorias — violações de políticas, riscos de dependência, problemas de controle de acesso e lacunas na cobertura de testes
Níveis de gravidade — Bloqueio (deve ser corrigido antes da fusão), Aviso (deve ser resolvido) e Informativo (somente para conscientização)
Diário de execução — O traço completo das etapas e ferramentas de avaliação usadas pelo agente, fornecendo transparência sobre como as conclusões foram alcançadas
Você também pode fazer perguntas complementares no bate-papo do DevOps agente: “Por que a análise sinalizou a alteração do IAM na linha 42?” ou “Quais repositórios dependem do endpoint da API que eu modifiquei?”
Integre com Kiro IDE e CLI
Para usar as revisões de código de prontidão de lançamento no Kiro:
Instale o DevOps Agent Kiro Power
do mercado Kiro Power O Power inclui habilidades que instruem o agente de codificação quando invocar revisões de preparação para o lançamento — após mudanças significativas no código e antes de criar um PR.
As descobertas aparecem diretamente no IDE, e a Kiro se oferecerá para corrigir os problemas identificados
Na CLI do Kiro, você também pode acionar revisões explicitamente: o agente de codificação invocará a revisão de preparação para o lançamento e incorporará as descobertas em seu fluxo de trabalho.
Integre com o Claude Code
Para usar as revisões de código de prontidão de lançamento no Claude Code:
Instale o plug-in DevOps Agent Claude Code do
mercado de plug-ins Claude Code O plug-in conecta o Claude Code ao seu Agent Space e permite que o agente de codificação invoque avaliações de prontidão de lançamento.
Durante o desenvolvimento, a Claude Code pode solicitar uma revisão das mudanças em andamento e abordar as descobertas antes de se comprometer
Integre com AWS Transforme de forma personalizada
Para usar as revisões de código de prontidão de lançamento no AWS Transform custom:
Baixe a habilidade AWS DevOps Agent Release Readiness Code Reviews do repositório de amostras personalizadas
AWS Transform em. GitHub Instale a habilidade em seu ambiente AWS Transform seguindo as instruções no README do repositório.
Depois de instalada, a habilidade se integra ao fluxo de trabalho de geração de código do AWS Transform. Quando o Transform gera ou modifica o código, a habilidade invoca uma revisão da prontidão de lançamento em relação às mudanças propostas.
Analise a superfície das descobertas diretamente na saída do Transform. Se os problemas forem identificados, o Transform poderá resolvê-los antes de finalizar a alteração do código.
Usando revisões de código em GitHub
Pré-requisitos: GitHub repositório conectado ao seu Agent Space com revisões automatizadas habilitadas. Para obter instruções de configuração, consulte Configurando a revisão de código e o teste automatizado.
As avaliações aparecem como comentários embutidos em diferenças de pull request, com um comentário de status geral
Configure como uma verificação de status necessária para bloquear mesclagens quando existirem descobertas de bloqueio
Usando revisões de código em GitLab
Pré-requisitos: GitLab projeto conectado ao seu Agent Space com análises automatizadas habilitadas. Para obter instruções de configuração, consulte Configurando a revisão de código e o teste automatizado.
As avaliações aparecem como comentários embutidos nas diferenças de solicitações de mesclagem, com uma nota geral
Configure como uma regra de aprovação de solicitação de mesclagem para exigir a resolução de descobertas de bloqueio
Usando revisões de código no bate-papo DevOps do agente
No bate-papo do DevOps agente, você pode:
Solicite análises de qualquer escopo de ramificação, confirmação ou repositório
Pergunte o que o agente sabe sobre as dependências do seu projeto: “Quais bases de código interagem com o serviço no repositório de pagamentos?”
Faça perguntas complementares sobre descobertas específicas
Solicite que o agente gere uma correção para um problema identificado
Visualize o gráfico de conhecimento de dependências para seus repositórios conectados
Corrimãos de segurança Agentic
As análises de prontidão para lançamento incluem barreiras de segurança integradas que evitam comportamentos comuns de agentes inseguros. Essas grades de proteção estão sempre ativas durante o processo de revisão. A cobertura específica e o comportamento de fiscalização podem mudar à medida que o recurso evolui. Embora nosso objetivo seja cobrir o maior número possível de comportamentos inseguros comuns, alguns comportamentos não terão barreiras de proteção correspondentes.
Prevenção de exposição a credenciais
O agente bloqueia qualquer chamada de ferramenta em que a entrada da ferramenta contenha padrões de credenciais comuns em texto simples, como AWS chaves, tokens de acesso e chaves privadas.
Detecção de exfiltração de arquivos confidenciais
O agente verifica e bloqueia comandos shell que combinam o acesso a caminhos de arquivos confidenciais com operações de rede, evitando tentativas de exfiltração de dados.
Mutativo AWS bloqueio de operação
O agente bloqueia qualquer chamada de AWS API que possa modificar sua infraestrutura. Isso evita que o agente de revisão faça alterações em seu AWS ambiente durante a análise. Read-only operações (describe, get, list) são permitidas; as operações mutativas são bloqueadas.
Read-only operações como describe_*get_*, e list_* são permitidas.
Aplicação de fases sequenciais
As fases de revisão da prontidão do lançamento devem ser executadas em sequência. Isso garante uma avaliação sistemática e completa e evita que avaliações incompletas sejam ignoradas.
