Controle de versão e gerenciamento de código

DESAFIOS E SOLUÇÕES PARA UM FLUXO DE VERSIONAMENTO DE CÓDIGO ÁGIL

 

No processo de desenvolvimento de um sistema computacional, um dos primeiros problemas que a equipe vai se deparar está relacionado com o versionamento de código. Como manter o código consistente? Como manter um histórico de todas as alterações feitas pela equipe? Como criar novas versões e recuperar versões antigas do projeto? Como gerenciar os conflitos no código quando mais de um desenvolvedor altera um mesmo arquivo?

A resposta para essas perguntas está no uso de um Sistema de Controle de Versão (VCS – Version Control System). Na Enacom, optamos por utilizar o Git, a ferramenta de controle de versão mais conhecida entre os desenvolvedores, focada em velocidade e desempenho. Futuramente falaremos mais sobre essa ferramenta, suas vantagens e desvantagens.

Com a adoção de uma ferramenta de controle de versão como o Git, novos desafios e novas perguntas são introduzidas no processo de desenvolvimento. Como utilizar o Git de maneira consistente e produtiva? Para responder essa pergunta podemos pensar em utilizar um fluxo de trabalho Git ou Git Workflow. Existem vários fluxos de trabalho Git divulgados e aqui nesse post vamos discutir sobre alguns deles e mostrar qual a opção escolhida pela Enacom.

1- Centralizado (ou Fluxo de Trabalho Centralizado)

O primeiro fluxo de trabalho a ser discutido é o centralizado. Nessa abordagem nenhuma ramificação (branch) do código é criada e os desenvolvedores trabalham diretamente no único ramo existente, o master. Como vantagem, esse fluxo de trabalho não necessita que a equipe tenha que gerenciar vários ramos de código. Como desvantagem, aumenta a probabilidade de existirem conflitos no código, já que todos os desenvolvedores estão utilizando o mesmo ramo de código, o que pode inserir bugs no sistema.

Images-02

 

Outra desvantagem do fluxo de trabalho centralizado é observada quando há a necessidade de criar uma nova release em produção e existem novas features no repositório que ainda não foram finalizadas e não irão compor a release. Nesse caso, será necessário adotar medidas para impedir que a feature não finalizada não faça parte da release.

2 – Feature Branch Model

Para resolver esse problema, existe um fluxo de trabalho chamado Feature Branch Model ou modelo de ramificação por recurso. Nessa abordagem, os desenvolvedores devem criar uma nova ramificação do código para cada feature a ser implementada. Com isso, o merge entre a feature e o ramo principal só acontecem quando aquela feature já tiver seu desenvolvimento finalizado. Assim, novas features nunca estarão no ramo master sem que a mesma esteja finalizada.

Images-03

Contudo, o modelo de ramificação por recurso ainda não evita um problema importante. Caso seja identificado um bug no código que está em produção não é possível realizar correções no mesmo código e gerar uma nova versão do sistema sem que as features desenvolvidas no intervalo entre a última release e a identificação do bug estejam presentes. Para corrigir o bug e gerar uma nova versão do sistema consistente, será necessário retroceder o código até a última versão, corrigir o problema e criar uma nova release a partir dessa correção.

3 – Forking Workflow 

Um outro fluxo de trabalho, comumente usado em projetos públicos de código fonte aberto é o Forking Workflow ou fluxo de trabalho de bifurcação. Nesse modelo, cada desenvolvedor possui seu próprio repositório e as modificações são realizadas somente nesse repositório. Para integrar o seu código com o repositório central, o desenvolvedor deve realizar o processo chamado de Pull Request. Isso faz com que os desenvolvedores integrem o código produzido sem a necessidade de realizar as modificações direto no repositório central.

Images-04

Entretanto, apenas o “gerente” do repositório poderá aceitar o Pull Request, fazendo com que o código seja realmente integrado. Isso faz com que os desenvolvedores tenham a capacidade de contribuir com o projeto, sem a necessidade de ter acesso ao repositório oficial. Essas vantagens acabando gerando a necessidade obrigatória da figura do “gerente”, que deverá revisar e aceitar os Pull Requests. O “gerente” normalmente é o desenvolvedor com maior conhecimento e capacidade técnica e deverá ficar destinado quase que integralmente a esse processo de análise, revisão e aceitação.

4 – Gitflow Workflow

Por último, o fluxo de trabalho Gitflow Workflow, proposto por Vincent Driessen em 2010, que define um modelo estrito de ramificação projetado em torno do lançamento do projeto.

No Gitflow Workflow, existem dois tipos de ramificações: ramificações principais e ramificações de suporte. As ramificações principais são chamadas de Develop e Master. A ramificação Master é onde se encontra o código correspondente ao software de produção. A ramificação Develop é um ramo criado a partir do ramo Master e é nesse ramo onde todos os desenvolvedores trabalham.

Images-05

As ramificações de suporte podem ser do tipo Feature, Release ou Hotfix. Ao iniciar o desenvolvimento de uma nova funcionalidade, o desenvolvedor deve criar uma ramificação do tipo Feature a partir do ramo Develop. Ele irá implementar a nova funcionalidade e mesclar o código produzido ao ramo Develop apenas quando finalizar a funcionalidade. Isso faz com que o ramo Develop tenha apenas funcionalidades finalizadas.

Images-06

Quando o ramo Develop atinge a maturidade e apresenta todas as funcionalidades necessárias para a criação de uma versão de software, um ramo do tipo Release é criado. Então, o ciclo de lançamento de nova versão é iniciado. Nesse momento, o código deve ser atualizado de forma a incluir correções, gerar documentação ou qualquer outra tarefa relacionada à criação da nova versão (novas funcionalidades não devem ser incluídas nesse momento). Quando a versão estiver pronta para ser lançada, o ramo Release é finalizado e mesclado aos ramos Develop e Master.

Images-07

O ramo do tipo Hotfix é criado caso seja encontrado algum bug no sistema em produção. Nesse caso, o ramo Hotfix é criado a partir do ramo Master, e ao finalizar as correções o ramo é finalizado e mesclado aos ramos Develop e Master.

Images-08

Ao avaliar um fluxo de trabalho para a equipe, é muito importante considerar a cultura da equipe de modo a adotar um workflow que aumente a eficácia da equipe e não seja um fardo que limite a produtividade. Alguns pontos a serem considerados ao avaliar um fluxo de trabalho do Git são:

  • Esse fluxo de trabalho escala com o tamanho da equipe?
  • É fácil reverter erros com este fluxo de trabalho?
  • Esse fluxo de trabalho impõe alguma nova sobrecarga cognitiva desnecessária à equipe?

Na Enacom, utilizamos o Gitflow Workflow para gerenciamento e controle de versões de software. Durante o ciclo de desenvolvimento de cada Sprint, os desenvolvedores criam ramos Feature para cada funcionalidade a ser implementada. Ao finalizar a funcionalidade, o desenvolvedor mescla a sua Feature com o ramo Develop e o nosso sistema de Integração Contínua disponibiliza o sistema em um ambiente de desenvolvimento para a equipe de qualidade. Em um post futuro, vamos explicar como o nosso sistema de Integração Contínua funciona e como ela está em conformidade com o Gitflow Workflow e com a equipe de qualidade.

Ao finalizarmos todas as funcionalidades da Sprint, um novo ramo Release é criado. A partir desse momento, uma versão de homologação é disponibilizada para a equipe de qualidade, que fica responsável por executar toda a bateria de testes já executada no ambiente de desenvolvimento. Caso todos os testes tenham sucesso, uma nova versão do sistema é implantada em produção.

A decisão pelo uso do Gitflow Workflow se deu inicialmente pelo perfil modular do fluxo de trabalho. Cada ramo tem uma funcionalidade específica e comporta uma versão do código. Por exemplo, o ramo Develop sempre irá comportar a versão de desenvolvimento do software, sempre apresentando funcionalidades já finalizadas. Outro exemplo, o ramo Master apresenta o código que está em produção.

Outra vantagem do fluxo de trabalho, é a facilidade na correção de eventuais erros que possam ser encontrados em qualquer um dos ambientes. Um bug mais crítico, encontrado em produção, pode ser facilmente corrigido a partir de um ramo Hotfix. Uma nova versão do sistema pode ser gerada de forma simples, com a criação de um ramo Release, e os desenvolvedores poderão continuar trabalhando no ramo Develop, sem criar conflitos entre a versão gerada e a versão que ainda está em desenvolvimento.

Por fim, o uso do Gitfow Workflow é facilitado, pela existência de várias extensões que auxiliam os desenvolvedores no gerenciamento dos ramos, fazendo com que a equipe não tenha que passar por um longo período de treinamento para adotar o fluxo de trabalho. Em outras palavras, para o desenvolvedor, o uso do Gitflow Workflow, implica apenas na criação e finalização de ramos do tipo Feature.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *