setembro 18, 2020

Dica da Semana: Git flow - GitHub flow - GitLab flow. Qual usar?

By agosto 04, 2020 0
Dica da Semana: Git flow - GitHub flow - GitLab flow. Qual usar? Imagem: D.R

Mais um novo artigo no portal! Hoje, conversei sobre diferentes fluxos de trabalho de trabalho para gerir como filiais ou projectos, durante o processo de desenvolvimento de software com nosso Git.

Esse artigo é parte do pressuposto de que, você já tem um conhecimento básico ou intermediário do Git, não me fornece informações detalhadas sobre os comandos do Git ou nas suas funcionalidades mais avançadas, pois esse artigo é sobre os diferentes fluxos de trabalho para trabalhar com o Git.

Primeiro, o que é o Git? 

O Git é um software ou sistema de controle de versão (Sistema de Controle de Versão) distribuído criado em 7 de abril de 2005 pelo Finlandês Linus Torvalds, ou mesmo o criador do Linux.

Houve uma discussão sobre os prós e contras do Git em comparação com os sistemas de controle centralizado, como:

O Concurrent Versions System (CVS) , desenvolvido em 23 de junho de 1986 pelo holandês Dick Grune.

O Subversion ou Apache O Subversion também conhecido como (SVN) desenvolvido pelo Apache Software Foundation.

Eu particularmente nunca usei nenhum dos dois projetos, pois sempre usei o Git para gerenciá-los. 

Prefiro ou Git comparando com outras ferramentas de controle de versão disponíveis. O Git hoje é o maior sistema de controle de versão, porque mudou muito a maneira como os desenvolvedores pensam em mesclar e ramificam os códigos de forma muito simples.

Os clássicos Version Control System como Concurrent Versions System e Subversion, a fusão e ramificação sempre foram muito difíceis, e esse é um dos motivos pelos quais o Git é muito popular hoje entre os desenvolvedores de software, pois é muito simples fazer esses trabalhos.

Um pequeno exemplo sobre o funcionamento básico do Git:

Se você ainda não está muito familiarizado com o Git ou tem alguma dúvida, deixa uma dúvida ou sugestão nos comentários para que possa escrever um próximo artigo apenas sobre o Git. Ou me mande uma mensagem estou em todas as redes sociais.

Agora vamos ao principal objectivo deste artigo: Explicar sobre os 3 diferentes fluxos de trabalho, vamos começar pelo mais “Popular”.

O que é o Git Flow?

Quando estamos trabalhando em pequenos projectos, é comum não termos um controle sobre o fluxo de desenvolvimento com Git nos nossos repositórios, porém, a complexidade do projecto e da equipe, vai recuperar coisas que antes eram simples e se tornam cada vez mais difíceis.

O Git Flow foi desenvolvido em 2010 por um engenheiro de software holandês Vincent Driessen. É um modelo ou conjunto de diretrizes que os equipamentos de desenvolvimento podem adotar para organizar como ramificações ou versão do seu código.

O Git Flow são diretrizes que você não precisa seguir todas elas. Na verdade, ou se eu recomendo que haja uma adaptação de acordo com uma equipe de desenvolvimento, isso indica 3 fluxos de trabalho diferentes para que sua equipe possa experimentar e encontrar o melhor que se enquadra para o seu contexto. Na empresa onde eu trabalhei, o GitHub Flow foi o que mais mostrou efeito para trabalhar em conjunto, já falei mais sobre frente.

Principais funcionalidades do Git Flow:

O Git Flow tem 5 funcionalidades dos quais, duas principais que são mestres e desenvolvem, outras três auxiliares. Que vamos conhecer melhor:

1-Master: está aqui onde temos todo o código de produção, todas as novas funcionalidades que estamos desenvolvendo, em algum momento será mesclado ou associado a essa filial mestre.

2-Develop : contém o código do nosso próximo deploy, isso significa que, como recursos ou funcionalidades, será finalizado e será adicionado nesta ramificação para posteriormente passar por mais uma etapa antes de ser associado a um mestre.

3-Feature branches: são branches para o desenvolvimento de uma funcionalidade específica, eles devem ter o nome iniciado por feature, por exemplo: feature / payment-system. É importante saber que essas ramificações de recurso são e são criadas sempre a partir do desenvolvimento da ramificação.

4-Release branches : tem uma confiança maior no desenvolvimento de uma filial e se encontra no nível de preparação para se juntar a um mestre e no desenvolvimento (caso alguma coisa tenha sido modificada na ramificação em questão.

5- Hotfix: é um ramo usado para corrigir erros encontrados no sistema. Elas são criadas a partir do mestre e não as alterações finais da filial (hotfix) devem ser juntadas tanto ao mestre da filial quanto ao desenvolvimento da filial.

Como você pode ver no exemplo acima, temos uma filial principal (com bolinhas azuis) como uma filial de produção. Também desenvolvemos uma ramificação (com bolinhas amarelas) onde cada mescla de desenvolvedor ou faz a mesclagem de suas mudanças de chegada das filiais apresentam e hotfixes.

As vezes criamos uma filial de lançamentos (lançamento) para implementar novas funcionalidades em produção. Se você sair de um bug no ramo de lançamento ou lançamento, correcções e produzido à medida que o ramo for alterado. Se você tiver um bug crítico ou hotfix em produção, crie um novo hotfix-branch, corrija um bug e um músculo ou faça uma mesclagem na ramificação de produção que é (mestre).

Esse fluxo de desenvolvimento é mais usado quando dificilmente lança novas funcionalidades no nosso sistema ou quando tem muitas opções em produção.

Fluxo do GitHub

Na minha opinião, esse é o mais simples e se tornou eficaz para o nosso contexto, nós usamos nos nossos projectos.

O Fluxo GitHub tem 6 principais tópicos que você precisa entender antes:

1- Criar uma filial:

O próprio GitHub na sua solicitação oficial solicita que crie uma filial quando você estiver trabalhando em um projecto, terá vários recursos ou ideias diferentes em andamento a qualquer momento, alguns dos quais estão prontos para serem usados ​​e outros que não.

Como ramos existem para ajudar a gerir esse fluxo de trabalho como você já sabe.

Ao criar uma filial no seu projecto, você cria um ambiente em que pode experimentar novas funcionalidades. Como as alterações feitas em uma outra filial não afectam uma entidade principal da filial, portanto, você pode experimentar e confirmar como alterações seguras de sua filial não serão mescladas até que estejam prontas para serem revisadas por alguém com quem você está colaborando ou alguém da sua equipe. 

Por esse motivo, é extremamente importante que sua nova filial seja criada para o principal da filial e trabalhe em uma funcionalidade ou correcção. O nome de sua ramificação deve ser descrito (por exemplo, autenticação de refator ou chave de cache de conteúdo do usuário), para outras pessoas que podem ver ou que estão sendo executadas.

2- Adicionando compromete-se:

Depois que sua ramificação para criada, é hora de começar a fazer alterações. Sempre que você adiciona, edita ou exclui um arquivo, você deve fazer um "commit" e adicionar uma filial. Esse processo de adição de "confirma" acompanha o seu progresso enquanto você trabalha em uma ramificação de funcionalidades. Os "commits" também podem criar um histórico transparente do seu trabalho, que outras pessoas podem seguir para entender o que você fez e por quê. Cada "commit" possui uma mensagem de "commit" associada a uma alteração que você não fez código, que é uma descrição que explica por que uma alteração específica foi feita. Isso permite que o reverter altere se um erro for encontrado ou se você decidir seguir uma direção diferente.

3-Abrir um Pull Request:

Os famosos “Solicitações de recebimento” iniciam discussões sobre seus commits. Como eles estão totalmente integrados ao repositório Git, qualquer um pode ver exatamente quais alterações alterações serão aceitas na sua solicitação ou "Pull Request".

Você pode abrir um "Pull Request" em qualquer momento durante o processo de desenvolvimento. Quando você tem pouco ou nenhum código, mas deseja compartilhar algumas capturas de tela ou idéias gerais, ou quando está parado e precisa de ajuda ou conselho, ou quando está pronto para alguém revisar seu trabalho. Você pode mencionar alguém no GitHub na sua mensagem de "solicitação de recebimento", pode solicitar feedback de uma pessoa específica.

4- Discussões e revisão de código ou Revisão de código:

Depois que um "Pull Request" é aberto, uma pessoa ou equipe que está revisando suas alterações podem ter perguntas ou comentários. Talvez o estilo de codificação não corresponda às diretrizes do projeto, ou a alteração esteja faltando nos testes. As solicitações de “solicitação de recebimento” são projetadas para incentivar e capturar esse tipo de conversa.

Você também pode continuar avançando para sua filial com uma luz de discussões e comentários sobre seus commits. Se alguém comentar que você esqueceu de fazer algo ou se houver um erro no código, poderá corrigir-lo em sua ramificação e alterar. O GitHub mostra seus novos commits e qualquer feedback adicional que você possa receber nas respostas unificadas de solicitação.

5- Implantar

Com o GitHub Flow, você pode implantar uma ramificação de desenvolvimento para teste final de produção antes da mesclar para um mestre de ramificação.

Depois que o seu "Pedido de recepção" for revisado e uma ramificação para testes em seus testes, você poderá implantar as alterações para verificação na produção. Se sua filial causar problemas, você poderá recuperar a implantação de uma filial principal existente em produção.

Equipa diferentes podem ter diferentes estratégias de implantação. Para alguns, pode ser melhor fazer ou implantar em um ambiente de teste especialmente. Para outros, fazer ou implantar diretamente na produção pode ser a melhor escolha com base em outros elementos no seu fluxo de trabalho (eu recomendo a primeira estratégia).

6- Mesclar

E por último ou famosa fusão.

Agora que suas alterações foram verificadas em produção, é hora de definir o código principal da filial. Depois de mesclados, o "Pull Request" preserva um registro das alterações históricas no seu código. Por ser pesquisável, ativar quem alguém não tiver tempo para entender por que e como uma decisão foi tomada.

Segue abaixo um outro (pequeno) exemplo sobre o fluxo de trabalho com o fluxo do GitHub:

 

Como pode ver, no exemplo acima Temos um branch master como um branch de produção. E os desenvolvedores podem criar ramificações para adicionar novas funcionalidades ou corrigir bugs e mesclá-los com uma ramificação de produção.

Parece muito simples, e é mesmo, esse fluxo também se encaixa na programação extrema ou Extreme Programming (XP) é uma metodologia muito difundida por Kant Voltar é um dos signatários do manifesto que é um ramo de produção que executa várias mudanças ao dia.

Fluxo GitLab

E, finalmente, o GitLab Flow.

Nessa última parte, vou explicar sobre o fluxo de trabalho do GitLab Flow, que também oferece uma maneira um pouco simples e transparente de trabalhar com o Git.

Como muitas organizações novas no Git não têm convenções sobre como trabalhar com o Git, seus repositórios podem se tornar confusos.

O GitLab Flow oferece também o uso do branch master e de suas alterações. Uma vez concluído como mudanças, ou mesclamos de volta a principal da filial.

1- Fluxo de produção com GitLab:

O GitHub Flow pressupõe que você pode implantar em produção toda vez que especificar uma ramificação de recurso.

Embora isso seja possível em alguns casos, como aplicativos de software como serviço ou SaaS, há muitos casos em que isso não é possível. Um caso em que você não controla o tempo de uma versão, por exemplo, um aplicativo iOS lançado quando passa a validação da AppStore. Outro caso é quando você tem períodos de lançamentos - por exemplo, dias úteis das 10h às 16h quando uma equipe de operações está em plena capacidade - mas você também faz o código de outros momentos.

Nesses casos, você pode criar uma ramificação de produção que reflita ou código implantado. Você pode implantar uma nova versão mesclando uma filial na produção. Se você precisar saber qual código está em produção, basta fazer o checkout da filial de produção para ver.

O tempo aproximado de implantação é facilmente visível quando a mesclagem é confirmada no sistema de controle de versão. Esse tempo é bastante preciso se você lançar automaticamente sua filial de produção. Se precisar de um tempo mais exato, seu script de lançamento poderá criar uma tag em cada lançamento. Esse fluxo evita sobrecarga de lançamento, tags e mescla que acontecem geralmente com o Git.

Ramos do ambiente com fluxo GitLab:

Pode ser uma boa ideia ter um ambiente atualizado automaticamente para um mestre de filial. Somente nesse caso, o nome desse ambiente pode ser diferente do nome do mestre da filial. Suponhamos que você tenha um ambiente de armazenamento temporário ou melhor armazenamento temporário, um ambiente de pré-produção e um ambiente de produção.

Nesse caso, você pode fazer ou implantar o preparo mestre da filial. Para depois de fazer ou implantar na pré-produção, crie uma solicitação de extração ou mesclagem do mestre da filial para uma filial de pré-produção.

Faça o lançamento ou a fusão da filial de pré-produção na filial de produção.

Esse fluxo de trabalho garante que tudo seja testado em todos os ambientes.

Nesse caso, não exclua uma ramificação de recurso.

Ramos de liberação com fluxo GitLab:

Você só precisa trabalhar com filiais de lançamentos se precisar lançar o software para os usuários. Nesse caso, cada ramificação contém uma versão secundária do software, por exemplo, 2.3 (estável) ou 2.4 (estável) e etc. Crie ramificações estáveis ​​usando um mestre como ponto de partida e ramificação mais tarde.

Ao fazer isso, você minimiza o período de tempo durante o qual precisa aplicar como correções de bugs em várias ramificações. Após anunciar uma ramificação de lançamento, adicione apenas como correções de bugs nas ramificações.

Se possível, primeiro faça ou mescle essas correções de bugs no mestre e, em seguida, selecione uma ramificação de lançamento. Se você começar a fazer ou mesclar uma ramificação de lançamento, poderá executar o risco de esquecer-selecionar como mestre e, em versões posteriores selecionadas ou o mesmo bug.

O GitLab Flow propõe usar esse modelo um pouco diferente da anterior, usando como ramificações de lançamentos ou lançamentos em vez de ramificações do ambiente.

 

Se Quiser se aprofundar Mais Sobre o Fluxo de Trabalho Acessa ESSA Documentação fazer gitlab, TEM MUITAS Lá Dicas boas Sobre Como Trabalhar com Esse fluxo de trabalho. 

Mas qual deles usar? Bom, como eu disse anteriormente, isso vai depender muito do seu produto, projeto e equipe. Mas vamos retomar algumas considerações. 

Fluxo do GitHub

Se o seu código tiver apenas uma versão em produção ou tempo todo (por exemplo, sites, serviços web e etc.), você poderá usar o recomendado: o github-flow. O principal motivo é que você não precisa fazer coisas complexas para o desenvolvedor. Depois que o desenvolvedor finaliza uma funcionalidade ou corrige um erro, ele é promovido para uma versão de produção.

Fluxo GitLab

Esse é o mais recomendável para empresas grandes com produtos que possuem milhares de usuários, por exemplo: twitter, google, netflix, amazon, quem são necessários para executar ramificações de implantação entre sua filial e o principal da filial, onde práticas de integração contínua e entrega contínua podem ser executadas antes de entrar em produção. A idéia é modificar mais proteção na versão de produção, que já é usada por milhões de pessoas.

Git Flow

Já esse, é mais recomendável se seu código tiver várias versões em produção (ou seja, produtos de software muito usados ​​como sistemas operacionais, Photoshop, aplicativos como instagram e etc.). O principal motivo é o qual você precisa oferecer suporte contínuo a versões anteriores que ainda estão em produção enquanto sua equipe desenvolve a próxima versão do sistema.

Muito obrigado pela sua atenção mais uma vez, até a próxima semana.

Ah, e não se esqueça de dar seu feedback ou compartilhar com seus colegas e amigos. 

Detalhe: Estou em todas as redes sociais caso queira conversar comigo.

 

Jovany Negócio

DevOps Engineer, Python Developer and Blockchain enthusiast. @DevOpsDays Luanda Organizer.

https://www.linkedin.com/in/jo%C3%A3o-neg%C3%B3cio/

Leave a comment

Deixe o seu comentário. Os campos com * são obrigatórios.

© 2020 Portal de T.I Todos Direitos Reservados