Controle de versões

Gerenciamento da Configuração de Software (GCS)

A GCS é um conjunto de práticas que proporciona o controle de todo o processo de desenvovimento de software, necessário pela complexidade envolvida no processo de desenvolvimento e pela grande quantidade de componentes de um software.

Fonte: Shutterstock.

Deseja ouvir este material?

Áudio disponível no material digital.

Praticar para aprender

Desenvolver um sistema definitivamente não é trabalho que se faça sozinho. O grau de exigência mental, a complexidade das construções algorítmicas e a grande quantidade de elementos a serem considerados na construção de um produto de software autorizam (ou quase obrigam) a convocação de mão de obra variada para que o desafio seja levado a bom termo. As consequências dessa união de forças são naturalmente benéficas, mas exigem providências bem coordenadas para o correto gerenciamento da evolução das versões do produto, sob pena de perda de controle das alterações feitas nessas versões.

Por isso, esta seção se dedica a abordar o conteúdo teórico associado ao controle de versões de software, incluindo o papel de um repositório e o necessário controle de compartilhamento de itens. Além disso, trata do funcionamento das principais ferramentas que auxiliam no gerenciamento da configuração de um software.

Chegamos ao desafio final desta unidade e, para bem cumpri-lo, devemos resgatar algumas situações que se apresentaram durante os desafios anteriores. Você está lembrado que, mediante uma situação desfavorável, assumiu a missão de introduzir uma metodologia de desenvolvimento de software na empresa em que havia sido contratado. Depois, com essa metodologia já amadurecida, você tratou de liderar a implantação de um modelo ágil de trabalho. Embora essas ações tenham sido a razão do salto de qualidade na empresa, ainda faltava uma última providência: implantar controle efetivo das versões dos produtos de software desenvolvidos.

Apesar de estarem cientes da importância de um sistema de controle de versões, os membros das equipes e os demais sócios da empresa estavam reticentes quanto a sua aquisição, afinal, bem ou mal, as produções eram razoavelmente bem controladas e todos tinham em mente o que seus colegas estavam desenvolvendo. Além disso, os custos de aquisição e de implantação de uma ferramenta dessas poderiam ser altos, o que diminuiria consideravelmente o benefício de sua adoção.

Assim, o desafio que agora se apresenta a você é o de novamente convencer seus pares quanto à adoção de um recurso, desta vez de um sistema de controle de versões de software. E novamente o meio de que você se utilizará será o da informação, com o adicional de uma exibição prática da ferramenta GitHub de controle de versão.

Para que a exibição seja possível, você deve realizar a instalação e a configuração do GitHub em qualquer computador disponível e apto a recebê-lo. Além disso, o procedimento deverá incluir também a criação do seu primeiro repositório de arquivos. Cada passo dessa sua atividade deverá ser registrado com um texto explicativo e a respectiva tela da etapa da instalação, de modo que seu trabalho possa servir como material de referência caso precise executar as mesmas ações no futuro. Mãos à obra!

Bom estudo e continue com a gente!

conceito-chave

Um software é um produto em constante evolução. Da sua concepção até a entrega (e além dela), ele nasce, cresce e carece de manutenção ao longo de um ciclo de vida bem definido e conhecido. Na condição de um produto dinâmico, seu processo de construção e sua manutenção requerem gerenciamento contínuo em todos os aspectos de sua construção e, mesmo em um estado considerado apto para entrega, um software passa por diversas modificações, e cada uma delas tem como resultado uma nova versão dele próprio. Por isso, um controle eficiente das revisões é necessário, o que é atingido por meio da utilização de uma ferramenta de controle de versões.

Gerenciamento de Configuração do Software

Embora o controle de versões seja o foco desta seção, será necessário contextualizá-lo em um tema mais abrangente, do qual ele faz parte como um elemento muito importante. Esse tema mais abrangente se chama Gerenciamento da Configuração do Software (GCS) que, de modo objetivo, é o meio pelo qual se proporciona controle a todo o processo de desenvolvimento de software (LEON, 2004). Esse controle se torna necessário, entre outros motivos, pela complexidade envolvida no processo de desenvolvimento e pela grande quantidade de componentes de um software.

A motivação maior para a criação e para a estruturação de uma disciplina que cuida da Gerência de Configuração de Software foi a necessidade de controlar as modificações pelas quais inevitavelmente passa um programa, o que é feito com o uso de métodos e de ferramentas e com o intuito de maximizar a produtividade e minimizar os erros cometidos durante a evolução.

Como o GCS não se resume a uma ação apenas, ele é composto por uma série de atividades bem definidas e estruturadas. De acordo com IEEE (2004), essas atividades incluem: gerenciamento e planejamento do processo de GCS, identificação de configuração do software, controle de configuração de software, controle de status de configuração de software, auditoria de configuração de software, gerenciamento da entrega e do lançamento de software e configuração das ferramentas de gerenciamento. A Figura 1.10 ilustra essas atividades em uma estrutura hierárquica.

Na sequência serão discutidas as três primeiras grandes atividades do SCM, colocadas nos retângulos da Figura 1.10, de acordo com IEEE (2004).

• Gerenciamento do Processo de CGS: conforme temos mencionado, o GCS controla a evolução e a integridade de um produto e o faz por meio da identificação dos seus elementos, pelo gerenciamento e controle das mudanças aplicadas e pela verificação, registro e relato das informações de configuração. Da perspectiva do engenheiro de software, o SCM facilita o desenvolvimento e as atividades de implementação de mudanças. Uma implementação de SCM bem-sucedida requer planejamento e gerenciamento cuidadosos, o que, por sua vez, requer compreensão do contexto organizacional e das restrições impostas ao projeto e à implementação do processo de SCM.
• Identificação da configuração do software: essa atividade identifica os itens a serem controlados, estabelece esquemas de identificação para os itens e suas versões e, por fim, estabelece as ferramentas e técnicas a serem utilizadas na aquisição e no gerenciamento de itens controlados.
• Controle de configuração de software: essa atividade trata do gerenciamento de mudanças durante o ciclo de vida do software. Ela abrange o procedimento para determinar quais mudanças fazer, a autoridade para aprovar certas mudanças, o suporte para a implementação dessas mudanças e o conceito de desvios formais dos requisitos do projeto.

Mesmo com a evidente necessidade de se gerenciar a configuração de um software, essa prática sofre com alguns mitos, muitos deles com potencial para desencorajar sua adoção nas organizações. Nas próximas linhas trataremos de três desses mitos e daremos bons motivos para que eles sejam desconstruídos, sempre com base na visão de Leon (2004).

• Mito 1 – Promover o gerenciamento da configuração de um software significa ter mais trabalho e adotar novos procedimentos: de fato a implantação e o gerenciamento adequados de uma sistemática de GCS não é uma tarefa simples. O período de transição entre um ambiente sem gerenciamento e um cenário de efetiva utilização de uma ferramenta para esse fim costuma ser difícil, já que novas habilidades devem ser desenvolvidas, novos procedimentos devem ser seguidos, entre outros desafios. No entanto, a transição será tão mais simples quanto mais eficiente for o trabalho das equipes de gerenciamento e de implementação do GCS. Ao utilizarem o sistema, os desenvolvedores e outros atores do processo de criação do software deverão compreender seus potenciais benefícios e o esforço que conseguirão evitar por meio da automação de tarefas e da eliminação de erros. Atualmente, as ferramentas de gerenciamento de configuração de um software automatizam todas as tarefas repetitivas, facilitando assim a atuação do pessoal envolvido com o produto.
• Mito 2 – O gerenciamento da configuração é de responsabilidade única do pessoal da administração do sistema: ao contrário do que sugere o mito, a implantação e a condução do GCS é responsabilidade de todas as pessoas envolvidas no processo de desenvolvimento de software embora a principal tarefa do pessoal da administração seja criar um ambiente organizacional no qual o GCS possa prosperar. Uma equipe de GCS precisa de todo o apoio do pessoal da administração para ter condições de implantar o sistema de gerenciamento da configuração aos poucos, pois é esse pessoal que deve monitorar a implementação e a operação do GCS, revisar periodicamente seu progresso e tomar as ações corretivas quando necessário.
• Mito 3 – O gerenciamento da configuração é apenas para os desenvolvedores: certamente as equipes de desenvolvedores constituem um dos mais frequentes usuários do GCS. Além disso, são os desenvolvedores que mais se beneficiam de um sistema de gerenciamento corretamente implementado. Problemas como perda de código-fonte, incapacidade de encontrar a última versão de um arquivo e reaparecimento de erros já corrigidos podem ser evitados com um sistema desses. Entretanto, há desenvolvedores que enxergam o GCS como perda de tempo e dele participam apenas por serem obrigados a isso. A potencial hostilidade voltada ao GCS pode ser eliminada se os desenvolvedores forem educados nos princípios da prática e esclarecidos sobre seus benefícios. As ferramentas atuais de GCS proporcionam um nível fenomenal de automação, o que acaba contribuindo para que outros atores do processo de desenvolvimento acabem se beneficiando delas, incluindo testadores e pessoal de qualidade, manutenção e suporte.

Controle de Versões

Feita a contextualização do Gerenciamento de Configuração do Software com o ambiente em que o controle de versões está inserido, avançamos para a abordagem desse tema. De acordo com Caetano (2004), o controle de versões é o meio pelo qual o GCS controla, de forma consistente, as modificações realizadas em um sistema. Isso ocorre por meio das seguintes funções:

• Recuperar versões anteriores do sistema.
• Auditar as modificações realizadas, levantando quem alterou, quando alterou e o que alterou.
• Automatizar o rastreamento de arquivos.
• Estabelecer meios para obter a situação de um projeto em determinado ponto do tempo.
• Prevenir conflitos entre desenvolvedores.
• Permitir o desenvolvimento paralelo do um ou mais sistemas.

Repositório

Todas essas funções parecem convergir para um elemento bem definido: a centralização dos dados. E se não tivéssemos essa centralização? Bem, o uso descentralizado de um arquivo de código-fonte, por exemplo, permitiria que vários programadores acessassem vários arquivos e cada alteração feita nele não seria refletida nos demais. Assim, o desenvolvimento paralelo seria inviável e o conflito entre desenvolvedores inevitável. O recurso que as ferramentas de controle de versão (abordadas a seguir) usam é o repositório, local em que programas em desenvolvimento, fotos, vídeos e demais arquivos ficam armazenados e podem ser acessados de forma controlada por todos os envolvidos no desenvolvimento do produto.

Baselines (Linhas de Base)

Um conceito importante no escopo do controle de versão é a baseline de software. As baselines representam conjuntos de itens de configuração formalmente aprovados, os quais servem de base para as etapas seguintes de desenvolvimento. Quando, no entanto, uma entrega formal é feita ao cliente no final de uma iteração, denominamos tal entrega de release. Baselines e releases são identificadas no repositório de programas, na grande maioria das vezes, pelo uso de etiquetas (tags) (DANTAS, 2009).

O termo também é usado para se referir a uma versão específica de um item de configuração de software que foi acordado e, em qualquer caso, a baseline só pode ser alterada por meio de procedimentos formais de controle de mudanças. Uma baseline, junto com todas as alterações aprovadas na linha de base, representa a configuração aprovada atual.

As comumente usadas são as linhas de base funcionais, alocadas, de desenvolvimento e de produto. A linha de base funcional corresponde aos requisitos de sistema revisados. A linha de base alocada corresponde à especificação de requisitos de software revisada e à especificação de requisitos de interface de software. A linha de base de desenvolvimento representa a configuração de um software em evolução, em momentos selecionados, durante o ciclo de vida do software. A autoridade de mudança para essa linha de base normalmente é da organização de desenvolvimento, mas pode ser compartilhada com outras organizações. A linha de base do produto corresponde ao produto de software completo e entregue para integração de sistema (IEEE, 2004).

Branches

A Gerência de Configuração de Software também permite que a implementação de novas funcionalidades por uma equipe seja realizada em paralelo, mas de forma isolada e independente das modificações de outros desenvolvedores. O isolamento é obtido com uso de ramificações (branches). As linhas de desenvolvimento (codelines) são designadas para cada projeto e são compartilhadas por vários desenvolvedores. A primeira linha de desenvolvimento definida no projeto é, por convenção, nomeada mainline. O ramo é criado no repositório e representa uma linha secundária de desenvolvimento, a qual pode ser unida novamente à linha principal (mainline) por meio da operação de junção (merge). Atualmente, a necessidade de atender, ao mesmo tempo, as múltiplas demandas do projeto tornam o uso de ramos um diferencial (DANTAS, 2009).

Ferramentas de Controle de Versão

Como era de se esperar, as funções próprias do controle de versões podem (e devem) ser executadas por uma ferramenta computacional, fato que naturalmente apresenta indiscutíveis vantagens em relação a uma eventual execução manual. O mercado disponibiliza ótimas ferramentas de controle de versão e três delas serão abordadas na sequência. Os critérios para adoção da ferramenta mais adequada deverão variar entre organizações, mas vale o alerta de que nenhuma decisão deve ser tomada com base na convicção de que ela fará as vezes de um compilador, de que substituirá o gerente do projeto, ou de que ela pode se tornar um meio de automatizar testes. Passemos, então, à discussão de duas das mais importantes e utilizadas ferramentas de controle de versão.

Git e GitHub

Nossa primeira providência, ao tratarmos das ferramentas Git e GitHub, será a de diferenciá-las. Apesar de terem nomes bastante parecidos e de serem produtos do mesmo desenvolvedor, suas funções são distintas: o Git é uma ferramenta de controle de versão bastante popular entre desenvolvedores e apresenta recursos de colaboração bastante aprimorados, incluindo fóruns de discussão para os projetos em desenvolvimento e para abordagem das alterações em curso. Presente também em outras ferramentas de controle de versão, os branches implementados no Git viabilizam o trabalho em paralelo entre membros da equipe e o controle de subprojetos que um desenvolvedor pode manter para experimentos próprios, incluindo correção de bugs e aprimoramento de funções, sem que os arquivos do repositório central sejam alterados e com a possibilidade de que seus experimentos sejam compartilhados (MAILUND, 2017).

O Git é um sistema de controle de versão gratuito e de código aberto, concebido para lidar com todos os projetos, desde os pequenos até aqueles bem grandes e que movimentam praticamente toda as equipes. Ele é bem fácil de ser aprendido e ocupará pouco espaço do servidor. Além disso, seu desempenho é bastante satisfatório. Mas e a segurança? Bem, o modelo de dados que o Git usa garantirá a integridade criptográfica de cada bit dos projetos. Cada arquivo e cada operação de commit passa por verificação de checksum, operação também aplicada em sua recuperação. Será impossível extrair qualquer coisa do Git além dos bits exatos que foram adicionados.

O recurso do Git que realmente o diferencia de quase todos os outros sistemas de controle de versão existentes é seu modelo de branching (ou ramificação). Com o Git, é possível ter vários branches nas máquinas locais, os quais podem ser independentes uns dos outros. As operações de criação, merge e exclusão dos branches leva alguns poucos segundos apenas. Com esse diferencial, as equipes poderão trocar de contexto quase que imediatamente, além de criar branches para experimentar uma ideia e, mesmo aplicando a operação de commit, voltar ao ponto de onde começou. O mesmo cabe para a aplicação de um patch, por exemplo.

O GitHub é equivalente ao repositório do Git, mas disponível em uma plataforma mundial e com acesso gratuito aos desenvolvedores que lá desejarem armazenar seus programas e compartilhá-los com outros desenvolvedores. Por meio da página de cadastro (GITHUB, c2020) é possível criar sua conta no GitHub e começar a fazer parte dessa grande comunidade. Bem, mas o que é possível obter com a criação de uma conta no GitHub além de um espaço para compartilhar código? A resposta mais simples vem com apenas uma palavra: visibilidade. Empresas de TI já consideram o repositório do candidato no GitHub como um dos critérios para sua contratação. Tamanha importância justifica nossa incursão por essa ferramenta, começando pelo passo a passo de cadastramento na plataforma.

1. Acesse a página de cadastro (GITHUB, c2020) e preencha os espaços com os dados solicitados.
2. Após a escolha de sua senha e da verificação da conta, a plataforma o levará para uma página em que você poderá escolher, nesta ordem:
   • Seu tipo principal de trabalho.
   • Seu nível de experiência em programação.
   • Qual o uso que você pretende dar ao GitHub.
   • Qual seu interesse (para que a ferramenta possa conectá-lo a comunidades com as mesmas afinidades que a sua).

Para essas opções, nossas escolhas foram: estudante, pequena experiência em programação, interesse em aprender o Git e o GitHub e resposta em branco, respectivamente.

3. Após a confirmação do seu endereço de e-mail, você será direcionado à tela em que poderá escolher o que deseja fazer primeiro: criar um novo repositório (ou um novo projeto), criar uma organização ou começar a aprender, conforme mostra a Figura 1.11.

4. Ao criar um novo projeto, a primeira ação a ser tomada é a escolha de um nome para o repositório, que estará atrelado ao nome de usuário que você escolheu no passo inicial. O nome escolhido para o repositório foi engsoft e a visibilidade escolhida foi a pública. Nenhuma opção de inicialização foi escolhida.
5. Neste ponto, uma tela com uma série de opções será oferecida, conforme ilustra a Figura 1.12.

A partir deste ponto, você pode criar seus arquivos de código ou fazer upload de um já existente em sua máquina.

Note o nome do usuário e o nome do repositório (roquemaitino/engsoft) na porção central e à esquerda da tela. Para que um arquivo estivesse disponível no repositório, foi feita a escolha de upload de um arquivo existente e, na sequência, acionado o botão de Commit. O arquivo escolhido foi Maior.java, uma aplicação simples em Java, que exibe o maior valor entre os oito informados pelo usuário via teclado.

Pronto! Ao acessar a página inicial desse perfil (MAITINO, 2020), você poderá ter acesso também à aplicação Java que disponibilizamos e alterar seu código por meio da criação de um branch.

CVS (Concurrent Version System ou Sistema de Versões Concorrentes) 

Trata-se de uma ferramenta open source que implementa as principais funções relacionadas ao processo de controle de versões. O CVS armazena em seu repositório as modificações realizadas num arquivo ao longo do tempo. Cada modificação é identificada por um número chamado revisão. Toda revisão armazena as modificações realizadas, quem realizou as modificações, quando foram realizadas, entre outras informações (CAETANO, 2004). A Figura 1.13 ilustra as principais funções realizadas pelo CVS.

O repositório CVS – assim como o de outras ferramentas – armazena uma cópia completa de todos os arquivos e diretórios que estão sob controle de versão. Normalmente, o desenvolvedor nunca acessa nenhum dos arquivos no repositório diretamente. Em vez disso, usa comandos CVS para obter sua própria cópia dos arquivos em uma área de trabalho e, em seguida, trabalha nessa cópia. Quando termina um conjunto de alterações, realiza uma operação chamada commit (ou confirmação) de volta para o repositório. Por isso, o repositório guarda as mudanças feitas pelo desenvolvedor, além de registrar exatamente o que e quando foi alterado e outras informações semelhantes. Observe que o repositório não é um subdiretório da área de trabalho ou vice-versa e que eles devem estar em locais separados (GNU, [s.d.]).

A estrutura geral do repositório é uma árvore de diretórios correspondente aos existentes no diretório de trabalho. Por exemplo, supondo que o repositório esteja em /usr/local/cvsroot, uma possível estrutura de diretório é mostrada na Figura 1.14.

Na estrutura de diretórios estão os arquivos de histórico de cada arquivo sob controle de versão. O nome do arquivo de histórico é o nome do arquivo correspondente com ‘, v’ anexado ao final. Os arquivos “index.php,v” e “frontend.c,v” são exemplos possíveis de arquivos de históricos. Eles guardam, entre outras coisas, informações suficientes para recriar qualquer revisão do arquivo, mais um log de todas as mensagens de commit e o nome do usuário que enviou a revisão. Os arquivos de histórico são conhecidos como arquivos RCS, porque o primeiro programa a armazenar arquivos nesse formato foi um sistema de controle de versão conhecido como RCS (GNU, [s.d.]).

Cada alteração feita no programa gera um novo número de versão que o identifica. O CVS atribui automaticamente números como 1.1, 1.2 e assim por diante para as versões geradas. Um arquivo pode ter várias versões e, da mesma forma, um produto de software pode ter várias versões. Esse produto geralmente recebe um número de versão como “4.1.1”. Cada versão de um arquivo possui um número de revisão exclusivo. Os números de revisão são semelhantes a “1.1”, “1.2”, “1.3.2.2” ou mesmo “1.3.2.2.4.5”.

Um número de revisão sempre tem um número par de inteiros decimais separados por ponto. Por padronização, a revisão 1.1 é a primeira de um arquivo. Cada uma delas recebe sucessivamente um novo número, aumentando o número mais à direita em um. A Figura 1.16 exibe algumas revisões, com as mais recentes à direita. Também é possível terminar com números contendo mais de um ponto, por exemplo “1.3.2.2”.

Antes de encerrarmos o conteúdo do CVS, vale tratarmos de mais algumas terminologias relacionadas ao assunto (GNU, [s.d.]).

• Checkout: denominação dada à primeira recuperação (ou download) de um módulo do sistema vindo do repositório do CVS.
• Commit: trata-se do envio do artefato modificado ao repositório do CVS.
• Export (ou Exportação): trata-se da recuperação (ou download) de um módulo inteiro a partir de um repositório, sem os arquivos administrativos CVS. Módulos exportados não ficam sob controle do CVS.
• Import (ou Importação): esse termo identifica a criação de um módulo completo no âmbito de um repositório CVS, feita por meio de um upload de uma estrutura de diretórios.
• Module (ou módulo): é a representação de uma hierarquia de diretórios. Um projeto de determinado software efetiva-se como um módulo dentro do repositório.
• Release: este termo equivale a um “lançamento”. Um número de release identifica a versão de um produto completo ou inteiro.

• Merge: refere-se à fusão das diversas modificações feitas por diferentes usuários na cópia local de um mesmo arquivo. Sempre que alguém altera o código, é necessário realizar uma atualização antes da aplicação da operação de commit, a fim de que seja feita a fusão das mudanças.

Este foi, portanto, o conteúdo que queríamos compartilhar com você. O entendimento de da importância do gerenciamento da configuração de um software e a familiaridade com os termos e o funcionamento de uma ferramenta de controle de versões são habilidades imprescindíveis para o desenvolvedor inserido em uma equipe de trabalho e ao gestor do software. Esperamos que este conteúdo seja útil a você em breve. Boa sorte e bons estudos!

Faça valer a pena

Referências

CAETANO, C. CVS – Controle de Versões e Desenvolvimento Colaborativo de Software. São Paulo: Novatec Editora, 2004.

DANTAS, C. Gerência de Configuração de Software. DevMedia, [S.l.], 2009. Disponível em: https://bit.ly/2LOcXP7. Acesso em: 26 out. 2020.

GIT FOR WINDOWS. Git for Windows – Version 2.29.2.3. Git for Windows, [S.l.], 2020. Disponível em: https://gitforwindows.org/. Acesso em: 13 dez. 2020.

GITHUB. Join. GitHub, [S.l.], c2020. Disponível em: https://github.com/join. Acesso em: 12 dez. 2020.

GNU. The Repository. GNU, [S.l., s.d.]. Disponível em: https://bit.ly/38incTg. Acesso em: 27 out. 2020.

IEEE Computer Society. Guide to the Software Engineering Body of Knowledge. Piscataway: The Institute of Electrical and Electronic Engineers, 2004.

LEON, A. Software Configuration Management Handbook. 3. ed. Boston: Artech House, 2015.

LONGEN, A. S. Como Usar Um Git Branch. Hostinger, [S.l.], 23 abr. 2019. Disponível em: https://bit.ly/3r8DGWC. Acesso em: 28 nov. 2020.

MAILUND, T. The Beginner’s Guide to GitHub. [S.l.: s.n.], 2017. E-book.

MAITINO, R. Roquemaitino/engsoft. GitHub, [S.l.], 2020. Disponível em: https://bit.ly/3nJHqfr. Acesso em: 12 dez. 2020.

VORMITTAG, R. A Practical Guide to Git and GitHub for Windows Users. 2. ed. [S.l.]: Reiter Consulting, 2016. E-book.