USO.
É o mesmo texto que aws deploy get-deployment help devolve dentro do CLImb.
USO
aws deploy get-deployment --deployment-id <d-XXXXXXXXX>
O estado do deploy: status (Created, InProgress, Succeeded, Failed,
Stopped), quantas máquinas em cada situação (deploymentOverview), o
motivo geral da falha (errorInformation) e o rollback (rollbackInfo).
Só o status, pra script:
... --query deploymentInfo.status --output text
Cada uma é um pedido de trabalho real; você resolve digitando o comando, e o estado fica salvo pro exercício seguinte.
Confira o portal-rh-producao: filtro de tag, role e configuração de deploy (qual é o padrão?).
Alguém subiu uma máquina e ela não recebeu deploy. Antes de culpar o CodeDeploy, traga só o filtro de tag do portal-rh-producao.
O deploy está rodando. Consulte pelo id — e consulte de novo até o status sair de InProgress.
O bot do chat do time avisa quando o deploy termina. Traga só o status do último deploy, em texto puro.
Veja o que o deploy fez na sua instância, etapa por etapa: parar, baixar, instalar, iniciar, validar.
A versão 2 do portal saiu do build como app.zip. Envie pro bucket como portal-rh-v2.zip, entregue no portal-rh-producao e acompanhe até terminar.
Hoje é dia de simulado: o QA preparou a versão portal-rh-v3-quebrado.zip, que quebra o health check de propósito. Envie o app.zip pro bucket com esse nome, entregue no portal-rh-producao e acompanhe até o fim. O deploy vai falhar — confira que o rollback automático disparou (rollbackInfo).
O rollback salvou a noite, mas o relatório do incidente precisa da causa. Liste as máquinas do deploy que falhou e veja, numa delas, a etapa que quebrou e o logTail do script.
Consulte o deploy uma vez e olhe o alias producao: ele continua na versão 1, mas com um RoutingConfig mandando 10% das chamadas pra versão 2. É o canary acontecendo.
Os 5 minutos de canary passaram sem erro. Consulte o deploy até ele terminar e confira: agora o alias aponta inteiro pra versão 2.
Veja o deploy do ponto de vista do alvo: o alias como alvo, as etapas (BeforeAllowTraffic, AllowTraffic, AfterAllowTraffic) e o peso da versão nova.
Sexta, 17h: a versão 3 foi pro canary e o monitoramento mostra erro de pagamento nos 10%. Reproduza — código novo, publique a versão 3 (descrição nova-bandeira), deploy com revisao-cobranca-v3.json e uma consulta — e pare o deploy com rollback. Confira que o alias voltou inteiro pra versão 2.
Entregue a revisão 2 com revisao-vitrine-v2.json no grupo vitrine-producao e consulte o deploy: ele para em Ready — as tarefas novas estão de pé no verde, e o tráfego AINDA vai pro azul.
Veja o alvo do deploy: dois conjuntos de tarefas, BLUE com 100% do tráfego e GREEN com 0%, cada um no seu target group.
O QA testou a versão nova no verde e aprovou. Libere o deploy e acompanhe até terminar.
Revisão 3 no ar pra teste: registre a nova task definition, entregue com revisao-vitrine-v3.json, espere o Ready — o QA reprovou. Pare o deploy com rollback e confirme que o tráfego nunca saiu do lado que estava atendendo.
O time corrigiu o que o QA achou. Registre a revisão 4, entregue com revisao-vitrine-v4.json, espere o Ready, libere depois do teste e acompanhe até terminar. Aí confira o listener: o tráfego voltou pro tg-vitrine-azul — a cada deploy, o lado que estava parado vira o novo.
aws s3 mbaws s3 cpaws ec2 run-instancesaws ec2 create-security-groupaws ec2 authorize-security-group-ingressaws iam create-policyaws iam create-useraws iam create-roleaws lambda create-functionaws dynamodb create-tableLer a sintaxe explica. Digitar fixa. No CLImb você roda
aws deploy get-deployment num terminal AWS simulado e vê a saída — inclusive
a mensagem de erro, quando erra a flag.