> For the complete documentation index, see [llms.txt](https://docs.skail.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.skail.dev/opere/configurar-e-hospedar/fazer-deploy-de-uma-nova-versao.md).

# Fazer deploy de uma nova versão

Os passos para publicar uma nova versão da sua aplicação no skail sem quebrar as execuções que estão em andamento na versão atual.

## Antes de começar: dois tipos de deploy

Se a mudança não altera a sequência de `await`s de nenhuma function (corrigiu o corpo de um command, mudou logs, adicionou uma function nova), você pode publicar com o mesmo `SKAIL_WORKLOAD`. As execuções em andamento retomam no código novo sem problema. Este guia é para o outro caso: a mudança altera o fluxo de uma function que tem execuções em andamento. Ver [Versionamento](/construa/conceitos/versoes-com-execucoes-em-andamento.md) para saber distinguir.

## Passos

1. Confira no Monitor se há execuções em andamento ou hibernadas nas functions que mudaram. Se não há, publique com a mesma versão e pare aqui.
2. Escolha a nova versão. `SKAIL_WORKLOAD` é `nome:versao`; a versão é livre, mas mantenha um esquema (`v1.3.0`, `v1.4.0`). A versão faz parte do endereço de cada function, então mudar a versão muda todos os endereços de uma vez.
3. Crie a versão no portal, em Workloads, com o mesmo nome e a nova versão. Ver [Workloads](/referencia/portal/workloads.md).
4. Publique a aplicação nova com `SKAIL_WORKLOAD=cobranca:v1.4.0`, sem derrubar a anterior. Em Kubernetes isso é um segundo Deployment (ou o mesmo chart com outro valor), não um rolling update do primeiro; em container, um segundo serviço; em App Service, um segundo app ou slot. As duas versões recebem execuções separadas e não interferem uma na outra. Em TypeScript, gere o build de novo com `--workload cobranca:v1.4.0` no `skail build`, o mesmo valor de `SKAIL_WORKLOAD`; com valores diferentes, a aplicação não sobe.
5. Aponte os novos triggers para a nova versão: o caminho passa a ser `/api/v1/trigger/cobranca/v1.4.0/...`. Se quem dispara é o seu próprio sistema, isso é uma configuração dele. Faça isso depois de ver a nova versão recebendo trabalho (uma execução de teste no Monitor).
6. Deixe a versão antiga rodando até esvaziar (drain). As execuções iniciadas na `v1.3.0` continuam endereçadas a ela e são retomadas só por ela, inclusive as que estão hibernadas em um delay de dias ou em uma espera por evento; não há migração automática para a versão nova. Acompanhe no Monitor pela versão.
7. Quando a versão antiga não tiver mais execuções em andamento nem hibernadas, derrube a aplicação antiga e despublique a versão no portal.

## Quando a versão antiga demora a esvaziar (drain)

Fluxos com esperas longas (uma régua de 30 dias, uma aprovação sem prazo curto) mantêm a versão antiga viva por semanas. Isso é normal e barato: a aplicação antiga fica ociosa entre as retomadas, mas o processo precisa continuar no ar. Se precisar encerrar antes, as opções são deixar as execuções vencerem o prazo da espera ou concluí-las disparando os eventos que elas esperam.

## Se você já publicou por cima

Fez rolling update com o mesmo `SKAIL_WORKLOAD` e mudou o fluxo de uma function: as execuções antigas vão falhar com erro de não determinismo (`SkailNonDeterministicException` em C#, `SkailNonDeterministicError` em TypeScript) na retomada e aparecer como falhas no Monitor. Publique de volta a versão anterior da function (mesmo nome, mesma sequência de `await`s), retome as execuções falhas manualmente, e refaça o deploy pelo procedimento acima. Ver [Retomada manual de execuções falhas](/opere/retomada-manual-de-execucoes-falhas.md).

## Na pipeline

O valor de `SKAIL_WORKLOAD` deve vir da pipeline (tag do build), não de um arquivo editado à mão: assim a versão publicada no skail e a imagem do container têm sempre o mesmo número. Em TypeScript, o mesmo valor vai no `--workload` do `skail build`. Chave e namespace vêm do cofre de segredos do environment de destino.

## Próximos passos

<table data-view="cards"><thead><tr><th></th><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><i class="fa-rocket">:rocket:</i></td><td><strong>Deploy sem quebrar execuções em andamento</strong></td><td>É o checklist operacional deste guia.</td><td><a href="/opere/deploy-sem-quebrar-execucoes.md">Deploy sem quebrar execuções</a></td></tr><tr><td><i class="fa-arrow-up-right-dots">:arrow-up-right-dots:</i></td><td><strong>Ambientes e promoção</strong></td><td>Para promover o mesmo build de hml para prod.</td><td><a href="/opere/configurar-e-hospedar/ambientes-e-promocao.md">Ambientes e promoção</a></td></tr><tr><td><i class="fa-cloud">:cloud:</i></td><td><strong>Como hospedar</strong></td><td>Para rodar duas versões lado a lado em cada plataforma.</td><td><a href="/opere/configurar-e-hospedar/container-kubernetes-e-azure.md">Container, Kubernetes e Azure</a></td></tr></tbody></table>