Escolher uma estratégia de fluxo de código
- 8 minutos
É importante escolher uma estratégia de fluxo de código adequada à maneira como sua equipe trabalha. Você tem várias estratégias a levar em consideração. No final do módulo, você pode explorar as opções. A equipe da Web da Tailspin decide desenvolver uma estratégia de fluxo de código baseada no Git e no GitHub.
Quando Clara configurou o Azure Boards, ela e a equipe identificaram algumas tarefas iniciais a serem realizadas. Uma tarefa era criar um fluxo de trabalho baseado em Git.
Vamos ver como a equipe está buscando uma maneira melhor de colaborar. Atualmente, eles estão usando um sistema de controle de versão centralizado, mas o plano é passar a usar o Git, um sistema distribuído.
Mara está trabalhando diligentemente nas funcionalidades atribuídas a ela quando Andy entra.
Andy: Olá, Mara. Na reunião de liderança dessa manhã, foi apontado que nossa equipe e a equipe de desenvolvimento de jogos estão usando sistemas de controle de versão diferentes. Para simplificar a forma como compartilhamos os recursos entre as equipes, nos pediram para mudar para um sistema de controle de versão distribuído capaz de lidar melhor com a colaboração.
Mara: É bom saber. Não sei se você se lembra, mas colocamos essa questão em discussão. Atualmente, estamos usando um sistema de controle de versão centralizado. Ele funciona muito bem para nós agora, mas concordo que um sistema de controle de versão distribuído é a melhor opção quando começarmos a compartilhar com outras equipes e a nossa equipe ficar maior. Também é uma tarefa de nosso quadro aumentar a visibilidade para que todas as partes interessadas saibam o que todos estão fazendo. Acho que um sistema de controle do código-fonte distribuído, como o Git, também ajudaria.
Paulo: Estou querendo experimentar o Git há algum tempo. Mas parece que nunca tenho tempo. Ele é difícil de aprender ou configurar? Se parecer razoável, talvez nós pudéssemos trabalhar nele agora. Estou cansado de sempre adiar as coisas. E seria bom poder ver o que cada um está fazendo e ter acesso a todo o repositório. E então, o que precisamos fazer?
Clara: Vou explicar, e você poderá decidir se parece algo que deveríamos implementar imediatamente.
Mara e Andy vão para o quadro branco para discutir sobre controle de versão.
O que são o Git e o controle de versão distribuído?
Mara: O desenho à esquerda representa o controle de versão centralizado, como o que estamos usando agora. Temos uma versão central da base de código 
no TFVC (Controle de Versão do Team Foundation) que todos usam. Cada um de nós trabalha nos arquivos que precisamos alterar e, depois, os mesclamos novamente no repositório principal quando terminamos de trabalhar neles.
Paulo: Sim, e isso está funcionando para nós. Quer dizer, exceto quando fui bloqueado daquela vez em que uma alteração interruptiva foi mesclada no repositório central.
Mara: Certo! Você foi bloqueado 
. Poderíamos usar uma estratégia de ramificação com o TFVC para resolver o problema de bloqueio, mas, em nossa configuração atual, a mesclagem poderia ser um pouco mais complicada. E quando tivemos aquela mudança disruptiva 
, ninguém conseguiu trabalhar até que resolvêssemos isso. Esse problema está sempre prestes a acontecer, porque todos nós usamos a mesma cópia do código.
À direita, temos um desenho do controle de versão distribuído. Ainda temos um repositório central 
que é a versão estável da base de código, mas cada desenvolvedor tem uma cópia 
própria na qual pode trabalhar. Isso nos libera para experimentar diversas abordagens sem afetar o repositório central.
O controle de versão distribuído também garante que apenas o código funcional 
seja mesclado no repositório central. Podemos até configurar o sistema de forma que o código não possa ser mesclado até ser revisado.
O que é legal no Azure DevOps é que ele funciona bem com sistemas de controle de versão centralizados e distribuídos.
Paulo: O que acontece quando mais de uma pessoa altera o mesmo arquivo?
Mara: Muitas vezes, o Git pode mesclar várias alterações automaticamente. Evidentemente, sempre queremos garantir que a combinação das alterações resulte em um código funcional. Quando não pode mesclar as alterações automaticamente, o Git marca os conflitos diretamente nos arquivos para que uma pessoa possa escolher quais alterações devem ser aceitas.
Paulo: No momento, nosso código está armazenado em nosso próprio servidor. Se passarmos para o controle de versão distribuída, onde o código será armazenado?
Clara: Que bom que você perguntou. É aí que entra a hospedagem.
Onde posso hospedar meu repositório?
Clara: Temos algumas opções quando estamos decidindo onde hospedar os repositórios. Por exemplo, podemos hospedá-los em um servidor local, no GitHub ou no Bitbucket. O GitHub e o Bitbucket são soluções de hospedagem baseadas na Web. Podemos acessá-los em qualquer lugar.
Paulo: Você já usou algum deles?
Mara: Já usei o GitHub no passado. Ele tem recursos importantes para desenvolvedores, como acesso fácil a logs de alterações e recursos de controle de versão usando a linha de comando ou o portal online.
Paulo: E como o Git funciona?
Como eu trabalho com o Git?
Mara: Como mencionei antes, com sistemas distribuídos, os desenvolvedores são livres para acessar todos os arquivos necessários sem afetar o trabalho de outros desenvolvedores porque eles têm sua própria cópia do repositório. Um clone é sua cópia local de um repositório.
Quando trabalhamos em um recurso ou em uma correção de bug, geralmente queremos experimentar diferentes abordagens até chegar à melhor solução. No entanto, testar o código em sua cópia da base de código principal não é uma boa ideia, pois talvez você não queira manter as primeiras tentativas.
Para oferecer uma opção melhor, o Git tem um recurso chamado ramificação, que permite manter quantas cópias você quiser e mesclar apenas a que quiser manter. Isso mantém a estabilidade do branch principal.
Andy: Até agora, entendi os conceitos. Como faço para registrar meu código?
Como minhas alterações locais são enviadas para a base de código principal?
Mara: No Git, o branch padrão, ou tronco, é tipicamente chamado de main.
Quando você achar que seu código está pronto para ser mesclado ao branch main no repositório central compartilhado por todos os desenvolvedores, crie o que é chamado de solicitação de pull. Quando cria uma solicitação de pull, você está dizendo aos outros desenvolvedores que tem código pronto para revisão e que deseja que ele seja mesclado com o branch main. Quando a solicitação de pull for aprovada e mesclada, ela passará a ser parte da base de código central.
Como é um fluxo de trabalho de ramificação?
Etapa 1: quando você começa a trabalhar em um novo recurso ou correção de bug, a primeira coisa que convém fazer é garantir que esteja começando pela base de código estável mais recente. Para fazer isso, você pode sincronizar sua cópia local do branch main com a cópia do servidor. Isso puxa para sua cópia local todas as alterações feitas por outros desenvolvedores que foram enviadas para o branch main no servidor desde a última sincronização.
Etapa 2: Para garantir que você esteja trabalhando apenas na sua cópia do código, crie um novo ramo específico para esse recurso ou correção de bug. Como você pode imaginar, ter muitas ramificações para tudo o que está fazendo pode ser difícil de lembrar, portanto, é fundamental ter uma boa convenção de nomenclatura.
Antes de fazer alterações em um arquivo, faça check-out de um novo branch para saber que está trabalhando nos arquivos desse branch, e não de outro. Você pode alternar entre branches a qualquer momento fazendo check-out desse branch.
Etapa 3: Agora, você tem segurança para fazer as alterações que quiser, pois elas serão feitas apenas em seu branch. Ao trabalhar, você pode fazer commit suas alterações no branch para garantir que não perca nenhum trabalho. Isso também fornece uma maneira de reverter as alterações feitas em versões anteriores. Antes que possa confirmar as alterações, você precisa preparar seus arquivos para que o Git sabe quais deles você está pronto para confirmar.
Etapa 4: a etapa seguinte é efetuar push (ou fazer upload) do branch local para o repositório remoto (como o GitHub), de modo que outras pessoas possam ver no que você está trabalhando. Não se preocupe, isso ainda não mesclará suas alterações. Você pode efetuar push de seu trabalho sempre que desejar. Na verdade, essa é uma boa maneira de fazer backup de seu trabalho ou de permitir que você trabalhe de vários computadores.
Etapa 5: esta etapa é comum, mas não é necessária. Quando estiver convencido de que seu código está funcionando como desejado, você poderá fazer pull do branch main remoto ou mesclá-lo de volta no branch main local. Estão ocorrendo alterações que seu branch main local ainda não tem. Depois que você sincronizar o branch main remoto com o seu, mescle o branch main local com o branch de trabalho e teste a compilação novamente.
Esse processo ajuda a garantir que seu recurso funcione com o código mais recente. Isso também ajuda a garantir que seu trabalho seja integrado perfeitamente quando você enviar seu pull request.
Etapa 6: agora, seu código local precisa ser confirmado e enviado por push para o repositório hospedado. Isso é o mesmo que ocorre nas etapas 3 e 4.
Etapa 7: finalmente, você está pronto para propor suas alterações para o ramo main remoto. Para fazer isso, você inicia uma solicitação de pull. Quando configurada no Azure Pipelines ou em outro sistema de CI/CD, essa etapa dispara o processo de build, e você pode ver suas alterações se movimentarem pelo pipeline. Quando o build for bem-sucedido e outras pessoas aprovarem seu pull request, seu código poderá ser mesclado no branch main remota. (Ainda cabe a um ser humano mesclar as alterações.)
Paulo: Tudo isso parece complicado e difícil de aprender.
Mara: O Git pode parecer assustador por ser bastante avançado, mas depois que você entende o fluxo, ele começa a parecer natural.
Você usará apenas alguns comandos por dia. Segue um resumo:
| Categoria | Para executar esta tarefa | Use este comando |
|---|---|---|
| Gerenciamento de repositório | Crie um repositório Git | git init |
| Baixar um repositório remoto | git clone |
|
| Ramo | Criar um branch | git checkout |
| Preparar e fazer commit das alterações | Ver quais arquivos foram alterados | git status |
| Preparar arquivos para commit | git add |
|
| Fazer commit de arquivos em seu branch | git commit |
|
| Sincronização remota | Baixar um branch de um repositório remoto | git pull |
| Fazer upload de um branch em um repositório remoto | git push |
Paulo: Parece um ótimo ponto de partida. Eu certamente consigo fazer isso. Posso aprender comandos mais avançados conforme precisar deles.