DevOps e deploys

acompanhe execuções de pipeline por ambiente, preserve tentativas e leia métricas de frequência, lead time e falhas 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