Pipeline Production

Arquivo: workflows/deploy-production.yml
Nome no Actions: Deploy to Amazon ECS

Trigger

on:
  push:
    branches:
      - main

Push na branch main após merge da release-X.Y.Z — etapa final da cadeia staging → canary → production.

Destino na AWS

Recurso	Valor
Região	`us-west-2`
Repositório ECR	`qyon-crm-geiko-service/production`
Cluster ECS	`qyon-crm`
Service ECS	`qyon-crm-geiko-production-svc`

Etapas exclusivas (antes do deploy AWS)

Production adiciona passos de versionamento e release que não existem em staging nem canary:

#	Step	O que faz
—	Create and Push Tag	Cria tag Git `X.Y.Z` e envia para `origin`
—	Check Latest Tag	Log da versão (validação)
—	Remove branch	`git push -d origin refs/heads/release-X.Y.Z`
—	Create GitHub release	Release oficial com notas em markdown

Git tag

git tag ${{ steps.extract_tag.outputs.tag }}
git push origin ${{ steps.extract_tag.outputs.tag }}

GitHub Release

Usa actions/create-release@v1 com:

Campo	Valor
`tag_name` / `release_name`	Versão semver (`X.Y.Z`)
`body_path`	`./release/release-X.Y.Z.md`
`draft`	`false`
`prerelease`	`false`
Token	`secrets.QYONDEVOPS_TOKEN`

O arquivo ./release/release-<versão>.md precisa existir no repositório antes do merge em main. Sem ele, a etapa Create GitHub release falha.

Após a release, o pipeline segue com credenciais AWS, build ECR e deploy ECS — mesmo padrão dos outros ambientes.

Build e deploy

ECR_REPOSITORY=qyon-crm-geiko-service/production
# push :X.Y.Z e :latest

aws ecs update-service \
  --cluster qyon-crm \
  --service qyon-crm-geiko-production-svc \
  --force-new-deployment

Fluxo completo

Checklist antes do merge em main

Branch de origem no formato release-X.Y.Z.
Arquivo release/release-X.Y.Z.md com notas da versão.
Validação prévia em staging e canary.
Secret QYONDEVOPS_TOKEN configurado no repositório (permissão para criar releases).