colibri-deploy-producao

Files (7)

• SKILL.md
• pipeline-colibri.md · references/
• aguardar-builds.sh · scripts/
• aguardar-execucoes.sh · scripts/
• conferir-deploy.sh · scripts/
• estado-repo.py · scripts/
• jira-resumo.py · scripts/

SKILL.md (first lines)

# Liberação para produção

Esta skill leva para produção os pacotes que uma ou mais tarefas do Jira entregam. O fluxo tem ações difíceis de desfazer: merge em `production*` e envio de pacotes ao S3, que chegam às lojas. O pedido do usuário autoriza essas ações para os pacotes das tarefas. Pare e pergunte ao usuário em cada ponto de decisão marcado com **Pergunte**, porque a resposta depende de regra de negócio ou de risco que o código não mostra.

Antes de começar, leia [references/pipeline-colibri.md](./references/pipeline-colibri.md). Ela explica a versão do pacote, as dependências do manifesto, o mapa de repositórios, o build, o deploy e os problemas conhecidos.

## Ferramentas

- `gh` autenticado na organização `ColibriAgile`.
- MCP do Atlassian: `getAccessibleAtlassianResources`, `getJiraIssue`, `searchJiraIssuesUsingJql`, `editJiraIssue` e `addOrEditJiraIssueComment`. As operações de versão vêm do `discover`: `getJiraProjectVersions` (com `executeRead`) e `manageJiraProjectVersion` (com `executeDestructive`). Chame o `discover` uma vez antes de usar essas operações.
- Scripts desta skill. Nesta skill, `scripts/` quer dizer `<pasta base da skill>/scripts/`: o harness mostra a pasta base quando carrega a skill. Use caminho absoluto nos comandos. Use uma pasta temporária só como pasta de trabalho, para clones e arquivos de saída.

| Script | Uso |
|---|---|
| `jira-resumo.py <arquivo.json>...` | Resume a tarefa salva pelo `getJiraIssue` (fixVersions, descrição, comentários com tabelas). |
| `estado-repo.py <repo>...` | Mostra, só com leitura, versões, dependências, workflows, execuções do master, PR abertos, releases e hotfixes não portados. |
| `aguardar-builds.sh <T0> <repo>:<wf>:<branch>...` | Acompanha os builds disparados pelo merge. Use com a ferramenta Monitor. |
| `aguardar-execucoes.sh <repo>:<runId>...` | Acompanha execuções pelo id (deploy, reexecução). Use com a ferramenta Monitor. |
| `conferir-deploy.sh <repo>:<runId>...` | Mostra a tag, o `.cmpkg` enviado e a contagem `Enviados/Ignorados`. |

## Lista de tarefas

Antes do passo 1, crie a lista de tarefas da sessão com estes itens. Atualize cada item quando ele terminar.

1. Ler as tarefas do Jira e listar os pacotes e as versões
2. Mapear cada pacote ao repositório e ao build
3. Separar os pacotes já liberados dos pacotes a liberar
4. Conferir as dependências do `manifesto.server`
5. Conferir o estado do master (builds e testes)
6. Conferir os branches relacionados e os hotfixes não portados
7. Conferir as versões do Jira e as tarefas pendentes nelas
8. Criar os PR para os branches de produção
9. Fazer o merge dos PR
10. Aguardar os builds e conferir as versões geradas
11. Disparar os deploys na ordem das dependências e aguardar
12. Lançar as versões do Jira
13. Gerar o relatório e comentar em cada tarefa

## Passo 1: Ler as tarefas

1. Obtenha o `cloudId` com `getAccessibleAtlassianResources`.
2. Para cada chave, chame `getJiraIssue` com `view: "full"`. O resultado passa do limite e o harness o salva em arquivo. Rode `python -I scripts/jira-resumo.py <arquivos>`.
3. Monte a lista de pacotes:
   - `fixVersions` dá os pacotes e a versão curta (por exemplo `POS 11.2`).
   - As tabelas dos comentários ("Pacotes para o QA", "Pacotes para baixar") dão a versão completa e o branch do build do QA. Para cada pacote, use a versão do comentário mais recente.
   - Um pacote só em `fixVersions`, sem versão completa, entra com a versão curta. Registre isso.
4. Junte as tarefas. Se 2 tarefas pedem o mesmo pacote com os 3 primeiros números diferentes, **Pergunte** qual versão vale.
5. Separe os itens "fora dos pacotes" (scripts do cloud, Catálogo cloud, configuração manual). Eles vão para o relatório como pendências.
6. Confira se o QA aprovou cada tarefa (status e últimos comentários). Se uma tarefa não tem aprovação, **Pergunte** se ela entra.

**Saída:** tabela com pacote, versão do QA, branch do build do QA e tarefa de origem.

## Passo 2: Mapear os repositórios

1. Use o mapa da referência para achar o repositório de cada pacote. Para um pacote fora do mapa, procure o `nome` do manifesto: `gh search code '"nome": "<Nome>"' --owner ColibriAgile --filename manifesto.server`. Se a busca falhar ou não achar nada, **Pergunte** o repositório ao usuário.
2. Rode `python -I scripts/estado-repo.py <repo1> <repo2> ...` com todos os repositórios. O script leva cerca de 20 segundos por repositório: use timeout de 600000 ms ou `run_in_background`. Guarde a saída: os passos 3 a 6 usam essa saída.
3. Para cada pacote, anote:
   - o `versao.ini` e o branch de produção que dispara o build (gatilho `push` do workflow);
   - o workflow de build;
   - o deploy: a entrada `tag_prefix` e se o `deploy.yml` repassa o `tag-prefix` para a action.

**Saída:** para cada pacote, repositório, `versao.ini`, branch de produção, workflow de build e forma de deploy.

## Passo 3: Separar já liberados e a liberar

Compare só os 3 primeiros números. O 4º número é o número da execução do workflow e sempre muda (veja a referência).

Para cada pacote:

1. **A liberar:** o `versao.ini` do master tem a versão esperada, e o master tem commits que o branch de produção não tem.
2. **Já liberado:** o branch de produção já tem a versão esperada, o master não tem commits novos para esse build, e existe release com essa versão. Confira se o deploy desse release já rodou: procure a execução do `deploy.yml` depois da data do release e confira o pacote com `conferir-deploy.sh`. Se o release existe sem deploy, o pacote volta para a lista de deploy (sem PR).
3. **Versão diferente:** o master ou a produção tem outra versão (maior ou menor). Não abra PR nem faça deploy desse pacote. Avise o usuário logo, com a versão esperada, a versão encontrada e quem liberou (PR, autor, data).

Avise o usuário em 1 frase, uma vez, que a comparação usa só os 3 primeiros números.

**Saída:** 3 listas: a liberar, já liberado (com ou sem deploy) e versão diferente.

## Passo 4: Conferir as dependências

Leia as dependências na saída do `estado-repo.py` (`manifesto.server` do master). O padrão é versão mínima (veja a referência).

1. Para cada pacote a liberar e cada dependência:
   - Se o pacote exigido está na lista de deploy, a versão dele tem de atender o padrão.
   - Se o pacote exigido não está na lista, ele tem de estar liberado em produção com versão que atende o padrão. Confira o último release de produção do repositório dele.
2. Dependências de infraestrutura (`Master`, `Guard`, `Launcher`, `DotnetCore`, `Sync`, `PGSql`, `Plugin_*`, `Binarios`, `Reports`, `NotaFiscal`) mudam pouco. Confira só as que o `estado-repo.py` marca com `<- mudou`.
3. Se uma dependência não está atendida, não faça deploy do pacote. **Pergunte** ao usuário: incluir o pacote exigido na liberação ou tirar o pacote dependente.
4. Monte a ordem do deploy: um pacote vai depois de todos os pacotes que ele exige. Em geral, os scripts vão antes das aplicações.

**Saída:** dependências conferidas e ordem do deploy.

## Passo 5: Conferir o estado do master

Na saída do `estado-repo.py`, confira a última execução de cada workflow de build e de testes no master de cada repositório a liberar.

- `success`: siga.
- Falha: leia o log com `gh run view <id> -R ColibriAgile/<repo> --log-failed`.
  - Falha do runner (por exemplo `MSB4166`, `SDK Resolver Failure`, rede): execute de novo com `gh run rerun <id> -R ColibriAgile/<repo> --failed` e aguarde.
  - Falha real de build ou de teste: não libere esse repositório. **Pergunte** ao usuário.
- `in_progress` ou `queued`: aguarde a conclusão antes do PR.

**Saída:** master sem falha em todos os repositórios a liberar.

## Passo 6: Conferir os branches

O objetivo é garantir que o master tem tudo o que o QA testou e que o merge não vai desfazer um hotfix de produção.

1. **Branches relacionados:** branches com a chave da tarefa no nome (`gh api repos/ColibriAgile/<repo>/branches --paginate --jq '.[].name' | grep -i <chave>`), branches citados nas tabelas do QA (coluna Branch) e PR abertos que citam a chave (`gh pr list -R ColibriAgile/<repo> --search <chave> --state open`). Ignore os branches sem relação com as tarefas.
2. Para cada branch relacionado que ainda existe, confira `gh api repos/ColibriAgile/<repo>/compare/master...<branch> --jq .ahead_by`. Um valor maior que 0 quer dizer commits sem merge no master. **Pergunte** ao usuário antes de seguir com esse repositório.
3. **Build do QA:** procure a execução do QA pelo número (o 4º número da versão do QA) com `gh run list -R ColibriAgile/<repo> --workflow <wf> --limit 200 --json number,headSha,headBranch`. Confira que o commit dela está no master (`compare/<sha>...master` com `behind_by` igual a 0). Liste os commits que o master tem a mais: eles vão para produção sem o teste do QA e entram no relatório.
4. **Hotfixes não portados:** o `estado-repo.py` lista os commits que estão só no branch de produção. Um hotfix que não está no master causa conflito no PR ou volta o código de produção para trás. Confira o conteúdo no master (um cherry-pick já feito também aparece na lista). Se falta o hotfix, mostre ao usuário o trecho de produção e o trecho do master e **Pergunte** se faz cherry-pick do hotfix no master.

**Saída:** branches relacionados sem commits pendentes, commits extras por repositório e hotfixes resolvidos.

## Passo 7: Conferir as versões do Jira

O passo 12 lança as versões do Jira (fixVersions) das tarefas. Uma versão lançada tem de conter só tarefas concluídas. Confira as versões antes dos PR, porque a decisão do usuário pode parar a liberação.

1. Liste as fixVersions de todas as tarefas: id, nome e `released`. Ligue cada versão a um pacote da liberação. O nome da versão usa a versão curta do pacote (por exemplo, `PIS 1.6` para o PIS 1.6.1).
2. Leia o nome atual de cada versão com `getJiraProjectVersions` (`versionId`). Outra pessoa pode renomear uma versão depois que a tarefa a recebe. Exemplo: a versão da tarefa era "CBO Connect 1.9.4" e passou a "CBO Connect 2.0", com outro escopo. Se o nome não corresponde mais ao pacote, **Pergunte**: criar uma versão com o nome certo e trocar a fixVersion das tarefas liberadas, ou não mexer.

From ColibriAgile/agents-instructions, MIT.

More from ColibriAgile/agents-instructions