Releases e testes

Guia completo na tela /releases/como-funciona (botão "Como funciona" na lista de releases).

• Release: uma versão de um projeto (ex.: App 2.4.0), com data prevista, issues vinculadas, ciclos de teste e notas da versão (rascunho gerado das issues resolvidas, editável, para copiar ou enviar ao cliente).
• Caminho da release (status): Planejada (planned: no plano, ninguém trabalhando ainda) → Em desenvolvimento (in_development: o time faz as issues) → Em teste (staging: o QA testa em ciclos de teste; antes se chamava Homologação) → Aprovada (approved: o gate registrou APPROVED, pronta para ir ao ar) → Em produção (production: foi ao ar). Cancelada (cancelled) sai do caminho e pode voltar para Planejada. PO/PM move o status; Aprovada normalmente vem da decisão APPROVED do gate; Em produção exige o gate APPROVED (sem ele, só admin, com justificativa), menos na OTA.
• Qual está no ar e qual é a próxima (momento da release): versão e OTA são trilhos separados: em cada projeto, a versão mais recente em produção é a versão no ar e a OTA mais recente em produção é a OTA no ar (current, "Em produção"); as outras em produção do mesmo trilho são anteriores (previous). A próxima (is_next, selo "Próxima") é a que vai ao ar em seguida no seu trilho: a mais adiantada no caminho (Aprovada, depois Em teste, Em desenvolvimento, Planejada) e, empatando, a de data prevista mais cedo. A lista de releases é separada em Em produção, Em teste (inclui Aprovadas), Próximas e Anteriores (inclui Canceladas).
• Atualização sem loja (OTA): release com tipo (kind) "ota", para o que chega aos aparelhos sem passar pela App Store ou Play Store. Crie uma release nova para cada OTA, com a versão que ela leva (ex.: 2.4.1) e o build. Pode seguir o caminho com ciclo de teste e gate, mas não precisa: hotfix por OTA vai ao ar em horas e o QA valida depois, já em produção. Por isso a OTA vai para Em produção de qualquer passo, sem decisão no gate, e pode até ser criada direto como Em produção (status "production") quando já foi enviada. Qualquer release que já foi ao ar fora do tracker (deploy do backend, versão publicada antes) também pode nascer Em produção, com a data em que foi ao ar. A página dela mostra a validação pelas issues vinculadas: quantas estão em Pronto para QA, Em teste, Aprovado e Reprovado. Publicada, ela vira a OTA no ar do projeto e a OTA anterior vai para Anteriores; a versão da loja continua no ar, porque são trilhos separados. Versão normal (loja ou deploy) é kind "version", o padrão.
• Na página da release, o topo diz em uma frase onde ela está, qual está no ar e qual o próximo passo (ex.: criar um ciclo de teste, terminar os testes, corrigir o que falhou, registrar APPROVED, publicar).
• Issue e release: o campo Release da issue diz em qual versão ela sai (a release principal), normalmente do projeto dela; quando a correção sai só em outro projeto (o deploy da plataforma, por exemplo), a principal pode ser a release de lá; o cartão do quadro e a issue mostram, por exemplo, "Sai na 2.4.0 · em teste". Quando o mesmo conserto sai em mais de um lugar (deploy do backend, OTA de cada runtime, console), as outras releases entram em "Também sai em", de qualquer projeto da empresa. A issue aparece em todas elas: na lista da release, no gate, nas notas da versão e na validação. A "Versão corrigida" do registro técnico é só a anotação do dev sobre o build da correção.
• Caso de teste: roteiro com passos e resultado esperado, reaproveitado em cada versão. Ciclo de teste: uma rodada de testes de uma release; cada caso recebe passou, falhou ou bloqueado, e um FAIL pode abrir uma issue já preenchida.
• Release Gate: decisão do QA de liberar (APPROVED) ou segurar (BLOCKED) a versão. O app sugere APPROVED quando há ciclo de teste com casos, todos os testes passaram e não há issue S1 aberta; S2 aberta só gera aviso.