> 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/construir/configurar-e-hospedar/como-fazer-deploy-de-uma-nova-versao-do-workload.md).

# Como fazer deploy de uma nova versão do workload

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](/aprender/fundamentos/versionamento-de-codigo-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](/construir/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.
5. Aponte os novos triggers para a nova versão: o caminho passa a ser `/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. 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 um `WaitForEvent`; 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

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 só consome recursos quando uma execução acorda. Se precisar encerrar antes, as opções são deixar as execuções vencerem o prazo do `WhenAny` 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 `SkailNonDeterministicException` 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](/operar/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. Chave e namespace vêm do cofre de segredos do environment de destino.

## Próximos passos

[Deploy sem quebrar execuções em andamento](/operar/deploy-sem-quebrar-execucoes-em-andamento.md) é o checklist operacional deste guia. [Ambientes e promoção](/operar/readme.md) para promover o mesmo build de hml para prod. [Como hospedar](/construir/configurar-e-hospedar/como-hospedar-worker-service-asp.net-core-container-kubernetes-azure.md) para rodar duas versões lado a lado em cada plataforma.