O desenvolvedor deve aguardar a conclusão do pipeline de IC ou iniciar a próxima tarefa depois de pressionar

8

Minha empresa está integrando o CI / CD; até agora, implementamos o CI pelo que entendi. Atualmente, quando um desenvolvedor envia código ao nosso repositório git, o pipeline do CI é executado.

Atualmente, nosso pipeline de IC inclui a construção do projeto e a análise estática do código para garantir que ele atenda aos nossos padrões de codificação. A seguir, implementaremos os testes. A compilação e a análise estática do código levam cerca de 3 minutos no momento. Pelo que li, corrigir problemas imediatamente é fundamental para o CI / CD. Espero que, quando adicionarmos testes de unidade, o pipeline possa levar cerca de 10 minutos para ser executado.

Portanto, minha pergunta é quando um desenvolvedor faz uma solicitação de pull / mesclagem, deve aguardar a conclusão do pipeline do IC ou simplesmente passar para a próxima tarefa e voltar para corrigir os problemas do pipeline, se existirem? Ou eles deveriam sentar e assistir o oleoduto correr?

continuous-integration git continuous-delivery

— iqueqiorio
fonte

7

Sentar e assistir o pipeline funcionar?

Não, não é assim que você trabalha com eficiência.

Os desenvolvedores enviam suas confirmações para o repositório de controle de origem e, em seguida, o pipeline de CI / CD é acionado.

Os desenvolvedores podem postar uma solicitação pull bem escrita sempre que quiserem. Geralmente, há uma marca visual que representa uma "construção em andamento" / "falha na compilação" / "compilação bem-sucedida".

Normalmente, um brach pode ser mesclado sempre que todos esses critérios forem atendidos:

pelo menos um aprovador / ou tantos que é necessário aprovar aprovou.
uma "compilação bem-sucedida"
sem conflitos de mesclagem não resolvidos

Se algum desses critérios não for atendido, eles precisam ser corrigidos, mas o desenvolvedor faz isso sempre que tiver tempo ou prioridade para executar esta tarefa.

— Jonas
fonte

2

Boa resposta. Muitas pessoas não sabem que, com o GitHub SaaS, é possível que o circle-ci ou outro IC crie as alterações propostas em uma solicitação pull antes que a alteração seja mesclada. Então, eu vi o GitHub Enterprise no local usado sem esse recurso: o Jenkins Farm no local só é executado quando você mescla o PR que pode ser quebrado, a menos que o desenvolvedor faça uma fusão e construção completa. Isso torna a vida muito mais complexa. Anos atrás, teamcity permite que você construa um ci em uma fazenda antes mesmo de se comprometer a impedir a quebra de um galho. Somente a construção após a publicação do problema é uma maneira legada de trabalhar.

— simbo1905 11/01/19

@ simbo1905 tudo de bom, exceto que a verificação de relações públicas não é 100% eficaz, a menos que seja totalmente serializada. Sobreposição de PRs significa que as respectivas alterações não se consideram e ainda podem interferir entre si, causando uma quebra quando elas chegam ao ramo de integração. Mesmo se eles não tiverem conflitos de mesclagem ou tocarem nos mesmos arquivos - conflitos funcionais ainda são possíveis.

— Dan Cornilescu

@DanCornilescu Os PRs aprovados podem passar por versões independentes, mas conflitantes. Um renomeia um método, um adiciona código que usa o antigo nome do método. Ambos os PRs passam compilações em paralelo. Quando aprovado e mesclado, o código não será compilado. Projetos grandes usam um bot de mesclagem como o bors-ng. O revisor não o mescla, eles dizem ao bot para tentar. O bot faz fusões em série somente após uma nova compilação, onde combinou o que está em sua fila de mesclagem. No nosso exemplo, ele tentará uma compilação mesclada dos PRs combinados. Ele falha e, portanto, tente apenas o primeiro adicionado à sua fila, tenha êxito, mescle, crie e rejeite o outro.

— precisa saber é o seguinte

1

Eu recomendo que você tente o seu melhor para garantir que o pipeline seja inferior a 10 minutos. Você pode executar seus testes em paralelo para ativar isso. Como jonas respondeu, eles podem gastar tempo criando uma solicitação de recebimento (enquanto o pipeline está em execução).

A troca de contexto é ruim para a produtividade; portanto, em vez de pegar outra tarefa, recomendo que o desenvolvedor use esse tempo para trabalhar em qualquer outra coisa relacionada à alteração que ele acabou de fazer. Talvez haja alguma documentação que possa ser atualizada relacionada a isso. Se é uma característica notável, ele pode criar um pequeno gif mostrando como trabalhar com ela. Mesmo olhando para a alteração de código novamente, pode ajudá-los a pensar em como poderiam melhorá-la na próxima vez. Esse tempo também pode ser usado na revisão de outros desenvolvedores de solicitações pull e alterações de código.

Se eles começarem a desenvolver outro recurso nesses 10 minutos, é provável que demore mais de 10 minutos antes que eles voltem a ele e o trabalho seja menos atualizado em sua mente. Se o IC falhar, será mais difícil para eles lembrar o que poderia ter dado errado e corrigir o código.

— Samuel Garratt
fonte

Isso é verdade: na minha opinião, o CI nunca deve demorar mais do que na máquina do desenvolvedor.

— Peter Muryshkin

0

Ok, então vamos supor que você tenha a ferramenta de controle de versão como a ferramenta Git e CI Jenkins. Portanto, o Dev cria um ramo de recurso para um problema. Você possui um pipeline de várias filiais ou um fluxo de trabalho em sua ferramenta de IC, que detecta essa ramificação de recurso na próxima varredura e executa as etapas de IC.

Portanto, as coisas que devem ser garantidas são:

Antes de aumentar PR / MR, o trabalho do IC é verde. Se não estiver verde, o PR / MR não deve ser aumentado. Obviamente, o desenvolvedor pode executar outras tarefas e, em seguida, voltar e corrigir o problema nessa tarefa, que é a sua escolha, dependendo da prioridade da tarefa. Você pode controlar o aumento de qualquer PR, verificando seus parâmetros de IC (se você não confia tanto no seu desenvolvedor e eles aumentam continuamente os PRs para versões quebradas)
Depois que o PR é gerado, um revisor de código revisará e mesclará se tudo estiver OK. O revisor de código pode ser qualquer outro desenvolvedor. Sua responsabilidade é revisar o código, verificar se ele está dentro dos critérios de "Definição de Concluído". DoD é principalmente um termo ágil, mas ágil e DevOps andam de mãos dadas.
Depois que o código é mesclado, o IC da ramificação principal deve ficar verde. Caso contrário, o código deve ser revertido e o problema deve ser corrigido, porque geralmente a ramificação principal também é implantada nos ambientes e não revertendo significa que todo o ambiente será quebrado.

Obviamente, as ações de pós-construção notificarão o comunicador de que Hey, você quebrou a compilação, para que os Devs possam executar suas outras tarefas, receberão emails de qualquer maneira.

— deosha
fonte