--- title: DevOps e deploys slug: devops-e-deploys docTags: createdAt: 2026-08-15T03:19:05.775Z --- :::BlockQuote Acompanhe execuções de pipeline por ambiente, preserve tentativas e leia métricas de frequência, lead time e falhas. ::: :::hint{type="info"} **Pré-requisito: ** Abra uma release existente. Para disparar pipeline real, é necessário vincular um projeto GitLab e uma branch ou tag; sem vínculo, é possível registrar uma execução manual. ::: *** A aba DevOps do detalhe da release conecta a versão ao histórico de deploys. Cada execução é um registro próprio, com pipeline, commit, branch, ambiente, situação, início, duração, tentativa e origem. Reexecutar acrescenta uma nova tentativa e nunca sobrescreve o registro anterior. Os cartões derivam métricas do histórico: frequência de deploy por semana, lead time até produção, taxa de falha e última execução em produção. Em caso de falha aberta, a tela troca a frequência pelo tempo da falha e sinaliza promoção bloqueada; isso explica por que uma release não pode avançar para Entregue. *** ### Passo a passo ::::WorkflowBlock :::WorkflowBlockItem **Abrir a aba DevOps** No detalhe de uma release, clique em DevOps. O cabeçalho continua exibindo versão, situação e os cartões de data, desvio e features. Na faixa Execuções de pipeline, observe o estado do GitLab, o vínculo de projeto/ref e o botão de ação principal. ::: :::WorkflowBlockItem **Entender o vínculo GitLab** Sem vínculo, a faixa apresenta Vincular GitLab. Clique no botão para abrir o diálogo e busque um projeto visível para a credencial do tenant; a busca é feita no GitLab. Selecione o projeto e informe Ref (branch/tag), normalmente main, depois confirme em Vincular. Com o vínculo salvo, a faixa mostra caminho do projeto e ref e o botão passa a disparar na forja. ::: :::WorkflowBlockItem **Disparar ou registrar a primeira execução** Com GitLab vinculado, use Executar pipeline para disparar uma execução real na forja. Sem vínculo, o botão é Registrar execução e cria um registro manual usando pipeline, commit, branch e ambiente informados no histórico disponível. Essa distinção de origem evita apresentar uma execução local como se fosse um pipeline vivo. ::: :::WorkflowBlockItem **Ler a tabela de deploys** A coluna Execução identifica o pipeline e o código da execução e mostra commit, branch, origem e responsável quando conhecidos. Ambiente separa Dev, Homologação e Produção; Início e Duração registram o tempo; Tent. mostra o número da tentativa; Situação usa Pendente, Executando, Sucesso, Falha ou Cancelado. ::: :::WorkflowBlockItem **Filtrar o histórico** Use a busca da tabela para procurar por pipeline, commit, branch ou responsável. Os filtros Origem, Autor, Ambiente e Situação funcionam como lentes sobre o histórico completo; filtrar não remove execuções da coleção e não provoca nova sincronização com a forja. ::: :::WorkflowBlockItem **Reexecutar sem perder a tentativa anterior** Quando já há histórico, o botão muda para Reexecutar pipeline, Reexecutar manualmente ou Reexecutar o código da falha. Em qualquer caso, uma nova execução é acrescentada e a anterior permanece na tabela. Se a falha estiver aberta, o código e, quando conhecido, o passo que falhou aparecem na mensagem de apoio. ::: :::WorkflowBlockItem **Acompanhar sincronização** Quando a release tem projeto GitLab, o Agility reconcilia o histórico uma vez por vínculo após carregar os dados. Sincronizado com o GitLab na carga confirma a reconciliação; Sem sincronização — o histórico pode estar defasado indica que a forja não respondeu, mas mantém o histórico local legível. ::: :::WorkflowBlockItem **Ler os indicadores de entrega** Frequência de deploy mostra a quantidade por semana e Lead time até produção mostra os dias entre a entrega e a chegada à produção. Taxa de falha resume a porcentagem de execuções com falha. Sem falha aberta, o quarto cartão informa Última em produção; com promoção bloqueada, ele informa Promoção bloqueada e o tempo de Falha aberta há. ::: :::WorkflowBlockItem **Usar o histórico para liberar a release** Uma execução com sucesso em Produção é o fato que permite promover a release para Entregue. Depois de confirmar o sucesso, volte ao botão Mudar situação no cabeçalho, informe data e resultados realizados e confirme a entrega. Se o deploy falhar, corrija a causa e use Reexecutar, preservando a tentativa com falha para auditoria. ::: :::WorkflowBlockItem **Desvincular o GitLab quando necessário** O chip do projeto vinculado contém o caminho e a ref e oferece o ícone de desvincular. Use-o quando a release precisar acompanhar outro projeto ou ref; depois refaça o vínculo pelo botão Vincular GitLab. Sem vínculo, o histórico local continua disponível e novas execuções usam o modo manual. ::: :::: :::hint{type="success"} :FontAwesome[]{icon="fa-solid fa-check"} **Verificação** - A tabela mostra ao menos uma execução com pipeline, commit/branch, ambiente, situação, duração e número de tentativa. - Uma reexecução cria uma nova linha e mantém a tentativa anterior no histórico. - Os cartões exibem frequência de deploy, lead time, taxa de falha e última execução em produção, ou sinalizam falha aberta/promoção bloqueada. - Com GitLab vinculado, o cabeçalho mostra projeto e ref e o botão indica Executar pipeline; sem vínculo, indica Registrar execução. - Depois de um sucesso em Produção, Entregue fica disponível no diálogo Mudar situação da release. ::: :::hint{type="warning"} :FontAwesome[]{icon="fa-solid fa-triangle-exclamation"} **Erros comuns** **Disparo sem projeto GitLab** O Agility informa Vincule um projeto GitLab antes de disparar o pipeline. Vincule um projeto e uma ref válidos ou use Registrar execução para documentar um deploy manual. **GitLab não configurado ou indisponível** Os chips GitLab não configurado e GitLab indisponível representam estados distintos. No primeiro caso, peça a configuração da integração do tenant; no segundo, aguarde a disponibilidade e tente novamente. O histórico local continua legível. **Ref ou pipeline recusado pela forja** Ref vinculada inexistente exige revincular a release a uma branch/tag existente. Se o pipeline for rejeitado, confira .gitlab-ci.yml, rules e permissões da ref antes de reexecutar. **Promoção bloqueada após falha** Quando a última execução relevante falha em Produção, o cartão Promoção bloqueada e o código da falha explicam o bloqueio. Reexecute para criar nova tentativa; não apague a execução com falha, pois a tabela é histórico imutável. **Métricas exibidas como travessão** Sem amostra suficiente, métricas como frequência, lead time ou última produção aparecem como —, e a tabela pode informar Nenhuma execução registrada. Registre ou execute o primeiro deploy para gerar o histórico. :::