Liberações (Releases) no Portal Nyverra: empacotar mudanças com rastreabilidade

Quando cinco mudanças precisam entrar em produção na mesma madrugada, o risco não é de cada uma isoladamente — é da coordenação. Alguém sobe primeiro, outro depende de um serviço que ainda não foi atualizado, e o rollback vira um quebra-cabeça. A gestão de liberações existe para organizar esse pacote.

Este guia detalha o módulo de Liberações do Portal Nyverra ITSM: o que é uma liberação, como ela se relaciona com as mudanças (RFC), os estados e transições, as validações de janela e as permissões que protegem o processo.

Interface do módulo no Portal Nyverra ITSM.

Liberação × mudança

A confusão é constante — e vale fixar desde já:

Conceito	O que é
Mudança (RFC)	A alteração individual, com tipo, risco, aprovação e implementação.
Liberação (release)	O pacote que agrupa uma ou mais mudanças que entram em produção na mesma janela.

Uma liberação pode conter várias mudanças, e a associação é N:N (com ordem no pacote). O sistema gera um código automático no formato REL-000001, REL-000002…

Atenção a um falso amigo: “Solicitar liberação” no WhatsApp Inbox não tem relação com este módulo — lá significa pedir ao operador que ceda a conversa. Release ITIL é em Gestão de serviços → Liberações.

Os estados de uma liberação

Estado	Significado operacional
Planejada	Pacote definido; janela e mudanças ainda editáveis.
Em andamento	Go-live em curso.
Concluída	Release encerrado; registro fechado para edição.
Cancelada	Pacote não será implantado (ou foi abortado).

As transições são controladas: de Planejada pode-se ir para Em andamento, Concluída ou Cancelada; de Em andamento, para Concluída, de volta a Planejada (reabrir) ou Cancelada.

Validações e regras do sistema

Situação	Comportamento
Liberação concluída ou cancelada	Não edita campos; não vincula nem remove mudanças.
Excluir liberação	Permitido apenas em Planejada ou Cancelada.
Fim planejado	Deve ser posterior ao início planejado.
Implantação real	Se informada, deve estar dentro da janela (início–fim).
Mesma mudança repetida	É ignorada (não duplica vínculo).

Um ponto importante de expectativa: o Portal não bloqueia concluir a liberação se alguma RFC ainda não estiver aprovada. Ele mostra o status de cada mudança vinculada, mas o “gate” de só subir com tudo aprovado é processo da sua empresa — valide no módulo de Mudanças e nas Aprovações.

Quem usa

Perfil	Uso típico
Gestor de release / técnico sênior	Planejar o pacote, definir janela, vincular mudanças e acompanhar o go-live
Operador com permissão RELEASE_*	Criar, editar status e manter o pacote atualizado
Administrador	Conceder permissões do módulo LIBERACOES aos perfis adequados

Como usar: passo a passo

1. Crie a liberação (Gestão de serviços → Liberações → Nova): título, descrição, ambiente alvo, janela planejada e responsável.
2. Vincule as mudanças na aba Mudanças vinculadas, colando o UUID da RFC (copiado do detalhe da mudança).
3. Inicie o go-live mudando o status para Em andamento.
4. Registre a implantação real (data/hora dentro da janela).
5. Conclua a liberação ao finalizar — ou cancele se o pacote não vai subir.

Permissões (RBAC)

Permissão	Permite
RELEASE_VIEW_ALL	Ver lista e detalhe
RELEASE_CREATE	Criar liberação
RELEASE_UPDATE_ALL	Editar, mudar status, vincular/desvincular mudanças
RELEASE_DELETE	Excluir (nos estados permitidos)

Se o menu não aparece ou ações falham com “sem permissão”, peça ao administrador para revisar o perfil.

Boas práticas

• Sempre agrupe na liberação correta as mudanças que sobem juntas — isso dá rastreio e auditoria.
• Nunca marque a liberação como Concluída sem alinhar ao que foi realmente implantado.
• Só faça o go-live com todas as RFC aprovadas (valide manualmente — o portal não impõe).
• Atribua um responsável pelo release: melhora a comunicação e a coordenação.
• Mantenha releases pequenos e frequentes: menor risco por janela.

Erros comuns

Situação	O que fazer
Não consigo editar/vincular	A liberação pode estar Concluída ou Cancelada.
Erro ao salvar datas	Confira fim > início e implantação real dentro da janela.
UUID inválido	Copie o ID completo do detalhe da RFC (formato UUID).
“Liberação concluída não pode ser editada”	Esperado — crie uma nova liberação para outro pacote.

Perguntas frequentes

Preciso aprovar a liberação em Aprovações pendentes?
Não. Aprove cada mudança no fluxo dela; a liberação é o registro do pacote.

O sistema impede concluir se uma RFC estiver pendente?
Não — a validação é manual, seguindo o processo da empresa.

Uma mudança pode estar em duas liberações?
Tecnicamente sim (N:N); use com critério (em geral uma RFC pertence a um release por janela).

Automatize via API

O módulo é exposto por API (/api/liberacoes, incl. implantar/cancelar e vínculo com mudanças). Referência em developer.nyverra.com.

Cenários de uso: releases na prática

1. Janela de manutenção de madrugada. Cinco RFCs precisam subir juntas às 23h. O gerente cria uma liberação, vincula as mudanças aprovadas, define a janela e coordena o go-live. Ao final, registra a implantação real e conclui. O pacote fica rastreável de ponta a ponta.

2. Release com rollback parcial. Durante a janela, uma das mudanças falha e precisa ser revertida. A liberação documenta o que subiu e o que voltou — evitando que “produção ficou num estado indefinido”.

3. Auditoria de mudanças em produção. Meses depois, pergunta-se “o que subiu naquela noite?”. A liberação responde: quais RFC, em que ordem, com que status e quando foi implantada. Sem o pacote, a resposta seria reconstruída por suposição.

KPIs de liberação

Indicador	O que revela
Releases por período	Cadência de entrega
RFCs por release	Tamanho do pacote (risco)
Implantações dentro da janela	Disciplina de execução
Liberações canceladas	Planejamento vs realidade
Releases sem mudanças vinculadas	Pacotes “vazios” ou mal registrados

Automação e integração

A liberação conversa com os demais módulos: as mudanças compõem o pacote; o Downtime Manager suprime alertas na janela; a Rastreabilidade guarda o histórico. Para reduzir risco, mantenha releases pequenos e frequentes — e sempre com o plano de rollback de cada RFC validado antes do go-live.

Checklist de implantação de liberações

1. Defina quem são os gestores de release (permissões RELEASE_*).
2. Estabeleça a política de tamanho de pacote (prefira releases pequenos).
3. Padronize a janela de manutenção e o vínculo com Downtime.
4. Exija plano de rollback por mudança do pacote.
5. Valide, antes do go-live, que todas as RFC estão aprovadas.
6. Registre a implantação real e conclua a liberação.

Perguntas frequentes adicionais

Por que o portal não bloqueia concluir com RFC pendente?
Porque o “gate” depende do processo da empresa; o portal mostra o status, mas a decisão de subir é humana.

Posso vincular a mesma mudança a dois releases?
Tecnicamente sim, mas o usual é uma RFC pertencer a um release por janela.

Como auditar o que subiu?
Pela liberação, que reúne as RFC, a janela e as datas de implantação.

Conclusão

Gestão de liberações transforma um conjunto de alterações em um pacote controlado, com janela, ordem e registro de implantação. Com o módulo de Liberações do Portal Nyverra ITSM, a ida para produção deixa de ser improviso e passa a ser um processo previsível e auditável.