Sistemas de controle de versão – também conhecidos como controle de código, sistemas de gestão de código-fonte ou sistemas de controle de revisões de código – são um mecanismo para guardar múltiplas versões de seus arquivos, de modo que, quando você modifica um deles, ainda tem acesso às versões anteriores. Eles também são um dos principais mecanismos de colaboração entre as pessoas envolvidas na entrega de um software.
Um controle de versão tem basicamente dois objetivos.
- Em primeiro lugar, ele deve guardar a cada versão de cada arquivo armazenado nele e garantir acesso a ela. Tais sistemas também fornecem uma forma de associar metadados – isto é, informação que descreve os dados armazenados – a cada arquivo ou grupo de arquivo.
- Em segundo lugar, ele permite que equipes distribuídas no tempo e no espaço colaborem.
Por que você precisa disso? Há algumas razões, mas em última análise trata-se de poder responder às questões abaixo:
- O que constitui uma determinada versão de sua aplicação? Como você pode reproduzir um estado específico dos binários de sua aplicação e a configuração que existia em um ambiente de produção?
- O que foi feito, quando, por quem e por quê? Essa não é uma informação ou quando as coisas dão errado, mas também é a história de sua aplicação.
Esses são os fundamentos do controle de versão. A maioria dos projetos nessa área usa alguma forma de controle.
O pipeline de implantação é um paradigma para mover o código do check-in para a produção de forma controlada. No entanto, é apenas um dos três graus de liberdade que você tem que trabalhar em grandes sistemas de software.
Mantenha absolutamente tudo sob controle de versão
Sistema de controle de versão
Uma das razões pelas quais optamos pelo termo controle de versão em vez de versionamento de código é que controle de versão não é somente para código. Qualquer artefato relacionado à criação de sua aplicação deve estar em controle de versão. Os desenvolvedores devem usá-lo para código, é claro, mas também para testes, scripts de bancos de dados, arquivos de compilação e implantação, documentação, bibliotecas e arquivos de configuração para sua aplicação, para seu compilador e todas as ferramentas relacionadas, e assim por diante, de modo que um novo membro da equipe possa começar do zero.
É importante guardar toda a informação requerida para recriar os ambientes de testes e de produção nos quais a aplicação é executada. Isso deve incluir informação de configuração para a plataforma na qual a aplicação roda e para o sistema operacional, que inclui arquivos de DNS, configurações de firewall e assim por diante. No mínimo, você precisa de tudo o que for necessário para recriar os binários e os ambientes nos quais a aplicação é executada.
O objetivo é armazenar de maneira controlada tudo que pode mudar em qualquer ponto do ciclo de vida do projeto. Isso permite que você recupere um snapshot exato do estado do sistema como um todo, do ambiente de desenvolvimento ao de produção, em qualquer ponto da história do projeto. Também é útil guardar os arquivos de configuração dos ambientes de desenvolvimento, porque isso permite que todos na equipe usem as mesmas configurações. Analistas devem guardar documentos de requisitos; testadores devem guardar os scripts de teste e seus procedimentos; e gerentes de projeto devem guardar os planos de versão, gráficos de progresso e logs de análise de risco. Em resumo, todos os membros da equipe devem guardar todos os documentos e arquivos relacionados ao projeto em controle de versão.
Voltamos a enfatizar a importância de uma boa gerência de configuração para um projeto. Se você não tem todos os artefatos do projeto em um sistema de controle de versão, não irá aproveitar os benefícios que discutimos aqui. Todas as práticas discutidas para reduzir o tempo de ciclo e aumentar a qualidade da aplicação, da integração contínua e testes automatizados à implantação com o apertar de um botão, dependem do armazenamento de tudo que está relaciona- do ao projeto em um repositório de controle de versão.
Além de guardar código-fonte e informação de configuração, muitos projetos também armazenam imagens binárias de servidores de aplicação, compiladores, máquinas virtuais e outras partes do conjunto de ferramentas de controle de versão. Isso é muito útil, pois acelera a criação de novos ambientes e, ainda mais importante, garante que as configurações básicas estejam completamente definidas e sejam boas. Ao armazenar tudo o que precisa em um repositório de controle de versão, você garante uma plataforma estável para ambientes de desenvolvimento, testes e produção. você pode guardar ambientes completos, incluindo sistemas operacionais de referência com configuração básica aplicada e imagens virtuais para um nível ainda maior de certeza e simplicidade de implantação.
Sistemas de controle de versão, além de permitir que organizações mantenham um histórico completo de cada mudança feita em suas aplicações, incluindo código-fonte, documentação, definições de banco de dados, scripts de compilação, testes e assim por diante, também têm outro proposito importante: capacitam equipes a trabalharem juntas em partes separadas de uma aplicação enquanto mantem um sistema de registro a base de código definitiva da aplicação.
Quando sua equipe cresce, pode ser difícil ter muitas pessoas trabalhando continuamente no mesmo repositório de controle de versão. As pessoas quebram a funcionalidade das outras por acidente, incomodando umas as outras. O objetivo é examinar como equipes podem trabalhar de forma produtiva com controle de versão.
Razões para criar um branch do código
O pipeline de implantação é um paradigma para mover código do check-in à produção de maneira controlada. Entretanto, ele é somente um dos graus de liberdade com o qual você pode trabalhar em um grande sistema de software. Há três boas razões para criar um branch do código:
- Primeiro, um branch pode ser criado para uma nova versão da aplicação. Isso permite que os desenvolvedores continuem trabalhando em novas funcionalidades sem afetar a versão pública lançada. Quando são encontrados defeitos, eles são corrigidos primeiramente no branch público, e as mudanças são então aplicadas na linha principal.
- Segundo, quando você precisa fazer um spike (um spike acontece quando criamos uma implementação descartável apenas para testar ideias, novas ferramentas, mudanças de design, esclarecer dúvidas, etc), com o propósito de adquirir mais informações e/ou criar uma prova de conceito) de uma nova funcionalidade ou de uma refatoração; o branch com o spike é descartado e nunca passa por um merge.
- Finalmente, é aceitável criar um branch com um curto tempo de vida quando for necessário fazer uma grande mudança na aplicação – um cenário muito raro se seu código for bem estruturado. O único objetivo desse branch é levar a base de código a um estado em que a mudança possa ser feita de maneira incremental ou por meio de branches por abstrações.
