6.2 Controle de Versão
O primeiro passo para se trabalhar com a Integração Contínua diz respeito ao uso e um sistema de controle de versão (Version Control System - VCS), responsável por gerenciar as mudanças realizadas no código fonte do produto ou da infra estrutura.
O uso do VCS facilita imensamente o gerenciamento e recuperação de versões específicas do nosso produto, além da manutenção do histórico das alterações realizadas ao longo do tempo.
Toda mudança realizada no código passa a valer após passarem por um commit (confirmação). O commit agrupa o conjunto de arquivos alterados e permite a inclusão de uma mensagem referente as alterações realizadas e/ou o que demandou tais alterações.
O VCS permite depois que se navegue pelos diferentes commits realizados, sabendo-se o que foi alterado, quem fez a alteração, e em que momento a alteração foi feita, dentre outras informações. Além disso, alterações concorrentes num mesmo arquivo podem gerar algum conflito que o VCS é capaz de detectar e tentar resolver de forma automática ou solicitando a intervenção humana para tal.
Desse modo, fazer uso de um VCS é obrigatório nos dias atuais e existem inúmeras opções disponíveis sendo uma das mais conhecidas o Git (https://git-scm.com/). O Git é um VCS distribuído e que não exige a existência de um único repositório central para todos os commits de um projeto. Cada desenvolvedor pode ter sua instância local do Git e diferentes Gits podem compartilhar os históricos de mudanças locais para outra instância de Git executando localmente em outra máquina. Desse modo, a opção por um servidor central é uma mera conveniência mas é possível utilizar o Git de forma distribuída sem a existência de um repositório central.
Práticas de DevOps como a Integração Contínua e a Entrega Contínua demandam extrema cooperação e disciplina dos envolvidos e o VCS facilita imensamente o controle dessa cooperação. Além disso, o que dispara a integração ou a entrega contínuas são os commits. Qualquer alteração que precise chegar até o ambiente de produção irá sempre iniciar com o commit das alterações demandadas.
Hoje existem diferentes ambientes que utilizam-se do Git para fornecer ferramentas de cooperação para o desenvolvimento de software e o processo de Integração Contínua (CI) e Entrega Contínua (CD). Dois exemplos bastante conhecidos são o GitHub (https://github.com/) e o GitLab (https://gitlab.com). Ambos permitem a criação de contas gratuitas, a criação de projetos, e a definição de pipelines de CI/CD.
O GitHub é bastante popular na comunidade open source. Muitos dos principais projetos abertos disponíveis atualmente tem seu controle feito no GitHub. O GitHub oferece ainda inúmeras ferramentas para a cooperação, relato de defeitos, solicitação de novas funcionalidades, e mais recentemente o chamado GitHub Actions, que viabiliza a criação de fluxos DevOps dentro do GitHub, permitindo processos de CI/CD, dentre outras.
Outro sistema de colaboração baseado em Git bastante popular é o GitLab. Basicamente ele oferece as mesmas funcionalidades do GitHub e pode até mesmo ser integrado a este. É possível criar projetos no GitLab importando projeto do GitHub e, posteriormente, manter a sincronia entre os mesmos. Além disso, o GitLab oferece também uma ferramenta para a criação de fluxos CI/CD que já é mais madura que o GitHub Actions e é a que utilizaremos nas seções a seguir para exemplificar a criação de um fluxo DevOps de Integração Contínua e Entrega Contínua.
Como em ambos os casos, o VCS que executa por baixo do GitHub ou do GitLab é o Git, a execução do Git via linha de comando é idêntica. Por exemplo, para verificar o log de commits no clone local de um repositório em minha máquina, basta executar o comando git log dentro do repositório, conforme demonstrado a seguir.
Como pode ser observado acima, a cada alteração confirmada no repositório, o Git registra as informações e guarda o seu histórico. Sendo um repositório distribuído, para identificar unicamente cada uma das confirmações recebidas, ele calcula um código hash, ou SHA. No exemplo acima observam-se dois commits, um iniciando por b76f569a e o outro, mais recente, iniciando por 4a649724. Caso seja necessário reverter o código para algum desses, a chave hash funciona como um identificador único (chave primária) para referenciar o respectivo commit.
Entretanto, essa não é a única forma de referenciarmos alterações em nossos códigos Git, é possível também atribuir tags a determinadas configurações de nosso repositório e utilizar essas tags como referências para se obter ou restaurar o código a determinado momento do tempo. Para mais informações sobre Git recomenda-se a leitura da documentação oficial disponível em https://git-scm.com/doc, ou busca na Internet pois existem inúmeros documentos sobre o seu uso.
Last updated