Pipelines CI/CD
Deploy automatizado do Geiko Service para ECS via GitHub Actions
As pipelines de deploy do Geiko Service (backend CRM) rodam no GitHub Actions e publicam imagens Docker no Amazon ECR, seguidas de um redeploy no Amazon ECS.
Os arquivos de referência ficam na pasta workflows/ deste repositório:
| Arquivo | Branch de trigger | Ambiente |
|---|---|---|
deploy-staging.yml | staging | Homologação |
deploy-canary.yml | canary | Canary |
deploy-production.yml | main | Produção |
Para as Actions executarem no GitHub, os YAMLs precisam estar em .github/workflows/ no repositório do serviço. A pasta workflows/ aqui serve como documentação e espelho dos arquivos oficiais.
Visão geral do fluxo
Todas as pipelines seguem a mesma base: detectar a versão a partir do nome da branch de release, buildar a imagem, enviar ao ECR e forçar novo deployment no ECS.
Comparação entre ambientes
| Item | Staging | Canary | Production |
|---|---|---|---|
| Trigger | Push em staging | Push em canary | Push em main |
| Repositório ECR | qyon-crm-geiko-service/staging | qyon-crm-geiko-service/canary | qyon-crm-geiko-service/production |
| Cluster ECS | qyon-crm-geiko-staging | qyon-crm-canary | qyon-crm |
| Service ECS | qyon-crm-geiko-staging-svc | qyon-crm-geiko-canary-svc | qyon-crm-geiko-production-svc |
| Região AWS | us-west-2 | us-west-2 | us-west-2 |
| Git tag + Release | Não | Não | Sim |
Remove branch release-* | Não | Não | Sim |
Convenção de versão
O deploy só prossegue se a branch de origem do merge corresponder ao padrão release-X.Y.Z (semver). O pipeline extrai X.Y.Z e usa como tag da imagem no ECR.
Exemplo: merge de release-2.4.1 → imagem .../staging:2.4.1 e .../staging:latest.
A detecção da branch funciona assim:
- Em PR merge, usa
GITHUB_HEAD_REF. - Em push direto na branch de ambiente, parseia a mensagem do último commit (
git log -1) procurando o sufixofrom <branch>.
Se o nome não bater com release-[0-9]+.[0-9]+.[0-9]+, o job falha na etapa Extract Tag from Branch.
Secrets e credenciais
| Secret | Uso |
|---|---|
AWS_CRM_ACCESS_KEY_ID | Autenticação AWS (ECR + ECS) |
AWS_CRM_SECRET_ACCESS_KEY | Autenticação AWS |
QYONDEVOPS_TOKEN | Apenas production — criação do GitHub Release |
Imagens no ECR
Em todos os ambientes o build gera duas tags para o mesmo repositório:
:<versão>— ex.:2.4.1:latest
O deploy no ECS usa update-service --force-new-deployment. O service precisa estar configurado para puxar a tag esperada (em geral :latest na task definition).
Pipelines por ambiente
Staging
Homologação — branch staging
Canary
Validação gradual — branch canary
Production
Produção — branch main + release