DevOps e deploys
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
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.
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.
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.
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.
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.
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.
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.
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á.
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.
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.
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.
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.