Análise do projeto arquitetural do GIT

Transcrição

1 Análise do projeto arquitetural do GIT Rafael Abraão Rodrigues Lago, Tiago Carmo Santos 1 1 rafael.abraao.rodrigues@gmail.com; tiagocarmosantos@hotmail.com; Abstract Este trabalho tem como objetivo realizar uma análise das decisões arquiteturais do sistema de controle de versão Git, bem como apresentar os benefícios, justificativas e consequências dessas decisões. A arquitetura é analisada através da identificação das principais demandas funcionais e os requisitos não-funcionais, demonstração das viewpoints estrutural e implantação, além de mapear os componentes e conectores COTS (Commercial Off-The-Shelf ) utilizados. Por último, discutiremos como a arquitetura influência no atendimento dos requisitos funcionais e não-funcionais, destacando os pontos fortes e fracos da solução. Keywords GIT; Sistema de Controle de Versão Distribuído; Projeto arquitetural de software; I. INTRODUÇÃO Utilizar um bom sistema de controle de versão é de fundamental importância para o sucesso de qualquer projeto de desenvolvimento de software. Empresas que não utilizam um sistema de controle de versão robusto e eficiente, muitas vezes enfrentam uma série de problemas, como por exemplo, resgatar versões mais estáveis do sistema e a dificuldade em realizar alterações quando diversos desenvolvedores trabalham simultaneamente no mesmo módulo. Diante deste contexto, o Git foi criado para solucionar alguns problemas das ferramentas de controle de versão da época. Sua missão é ser um sistema open source para controle de versão distribuído e gestão de código-fonte, sendo projetado para lidar com os mais diversos tipos de projetos, desde os menores até os mais complexos, com velocidade e eficiência. O presente artigo tem como foco analisar os aspectos arquiteturais do sistema de controle de versão Git, fazendo uma relação de como as decisões arquiteturais impactaram nos requisitos funcionais e não-funcionais. Para isto, explica o motivo pelo qual o Git foi criado e aponta os seus principais requisitos. A arquitetura é apresentada através da visão estrutural, ou seja, identifica e define os principais componentes e conectores, assim como a visão de implantação, que tem como objetivo demonstrar como é realizada a comunicação entre os repositórios distribuídos em uma rede. Veremos as razões pela qual o criador do Git não adotou uma linguagem orientada a objetos e menciona as bibliotecas COTS usadas na sua implementação. Ao final, discute como a arquitetura adotada induziu no atendimento dos requisitos, destacando os pontos fortes e fracos da solução. Este documento está dividido nas seguintes seções: Na próxima seção, o sistema é apresentado detalhando seu principal objetivo, motivo da sua criação, requisitos funcionais e não-funcionais. Na seção seguinte, é demonstrada a arquitetura através das visões de estrutura (define os principais módulos (componentes) e os conectores utilizados na interação entre eles) e de implantação (define os nós de processamento que o sistema requer para a sua instalação, a exemplo dos requisitos mínimos de memória e processamento), além de descrever o motivo pelo qual as decisões arquiteturais foram tomadas. A quarta seção tem como objetivo realizar o mapeamento do modelo arquitetural nos artefatos de implementação, apresentando possíveis frameworks, middlewares, componentes e conectores COTS utilizados. Na última seção, os pontos fortes e fracos serão analisados e discutiremos como os requisitos não funcionais induziram as decisões arquiteturais. II. GIT O Git é um sistema de controle versão distribuído com código-fonte aberto e tem como principal objetivo registrar as mudanças feitas em um arquivo ou um conjunto de arquivos ao longo do tempo, permitindo dessa forma analisar as atualizações com detalhe, desde a primeira versão até a última. O projeto para construção do Git teve inicio no ano de 2005, após desentendimento entre a comunidade que construía o kernel do Linux e a empresa que desenvolvia comercialmente o BITKEEPER, um sistema proprietário de controle de versão distribuído, utilizado para armazenar o código-fonte do kernel Linux. Isso levou a comunidade open source, em particular Linus Torvalds, o criador do Linux, a desenvolver sua própria ferramenta baseada nas lições que eles aprenderam ao usar o BITKEEPER. Os principais motivos que levaram Torvalds a construir seu próprio projeto foram à suspensão das licenças do BITKEEPER por parte do fabricante e a falta de um sistema de controle de versão que atendesse os requisitos desejados por ele [2]. O projeto do GIT é uma síntese da experiência de Torvalds com a manutenção do desenvolvimento altamente distribuído do projeto do Linux, junto com seu íntimo conhecimento de desempenho de sistemas de arquivos (conhecimentos adquiridos no mesmo projeto) e a necessidade urgente de produzir um sistema funcional em um curto espaço de tempo [1]. Levando em consideração essas influências, alguns requisitos funcionais e não-funcionais foram definidos:

2 2 A. Requisitos funcionais Um das principais vantagens do Git é a possibilidade do desenvolvimento não-linear, permitindo dessa forma que os repositórios sejam criados localmente. Apesar do Git sofrer uma forte influência da arquitetura do BIT- KEEPER, este requisito não existia no sistema proprietário. Provavelmente este requisito tenha sido inspirado no Monotone, um sistema de controle de versão distribuído iniciado em 2003 [2]. Outro fator relevante é o desenvolvimento distribuído, dando a capacidade ao usuário de possuir uma cópia local completa de todo o histórico do projeto, facilitando dessa forma os comandos de branches e merges[1].outra vantagem deste modelo é a possibilidade do programador trabalhar de forma off-line,já que o repositório não tem a necessidade de se comunicar com um servidor central através da rede, melhorando e muito o desempenho e flexibilidade das operações. O histórico do Git é salvo de uma maneira que o nome de uma determinada revisão (commit) depende de todo o histórico de desenvolvimento que leva até este commit. Uma vez publicado, não é possível mudar as versões antigas sem passar despercebido. A estrutura é similar a uma árvore hash, mas com dados adicionais nos nós e nas folhas [1]. O Git foi modelado como um conjunto de programas escrito em C e numerosos scripts em shell, que encapsulam estes programas. Embora muitos destes scripts tenham sido reescritos em C, como parte do esforço para tornar o sistema compatível com o Windows, o modelo básico continua, sendo fácil agrupar seus componentes [1]. O Git armazena cada novo objeto criado como um arquivo separado. Embora cada arquivo seja individualmente comprimido, isso requer um espaço considerável no disco e é ineficiente. Isto é resolvido com o uso do garbage collection, que armazena um grande número de objetos em um único arquivo. Esta operação é realizada periodicamente de forma automática, porém pode ser feita manualmente através do comando git-gc [1]. Um dos motivos apontados por Linus Torvalds para criação do Git foi o fato de não existir na época um sistema que atendesse ao requisito de desempenho, portanto, a arquitetura do sistema foi fortemente impactada por este requisito não-funcional. Existe um grande número de s sobre desempenho na lista de desenvolvedores do GIT, levando a entender que esta é a principal preocupação. Outro requisito não-funcional importante é a escalabilidade. Torvalds descreveu o Git como sendo um sistema veloz e escalável, já que não fica mais lento com o aumento do histórico do projeto [1]. Outro aspecto importante é a portabilidade entre as diversas plataformas. Inicialmente desenvolvido para Linux, mas pode ser usados em outros sistemas operacionais baseados no Unix, incluindo o BSD, o Solaris e o Darwin. O Git também roda no Microsoft Windows [1]. A comunicação entre os repositórios pode ser realizada através dos protocolos HTTP, SSH, FTP e Git protocol. III. PROJETO ARQUITETURAL Esta seção tem como principal objetivo demonstrar os estilos e visões arquiteturais do sistema GIT. As visões arquiteturais são apresentadas através das viewpoints estrutural e de implantação. Do ponto de vista, da viewpoint estrutural, o sistema GIT apresenta o estilo arquitetural Virtual Machine. Dividido em camadas que fornecem serviços diversos, através de programas independentes. O estilo arquitetural identificado pode ser especializado como uma Maquina Virtual Estrita, onde programas de um nível podem acessar somente serviços disponibilizados pela camada imediatamente inferior. A Figura 1 ilustra as três camadas do sistema GIT, identificando posteriormente os principais componentes e conectores de cada camada. Entretanto a camada GIT Gui não será detalhada, pois a mesma pode ser implementada de diversas formas, desde que o desenvolvedor tenha o conhecimento necessário para realizar chamadas aos componentes do GIT Core. Para mais informações veja no índice de referências o item [4]. B. Requisitos não-funcionais Figura 1. Visão Estrutural do GIT A. Visão Estrutural do Core A Figura 2 ilustra os componentes e conectores que constituem a camada central do GIT, o Core MsysGIT Version Esse core representa uma versão para

3 3 Windows e viabiliza a execução dos comandos GIT sobre essa plataforma. Logo abaixo, segue uma breve descrição: Shell Linux - Constituído pelo programa GNU Bash, Version 3.1.0(1)-Release-(i686-pc msys), um Command Language Interpreter. Sobre o qual executa uma coleção de programas independentes, que representam os comandos básicos do Sistema Operacional Linux, a saber, ls, kill, find e etc. Dentre essa coleção de programas esta o executável do GIT executado logo após a autenticação do usuário padrão do GNU Bash. Para suportar algumas funcionalidades do GIT, o Bash disponibiliza uma serie de programas e bibliotecas COTS (Commercial offthe Shelf ), como por exemplo o aplicativo curl.exe e a biblioteca libcurl.dll, responsáveis por fornecer ferramentas para transferência de dados de/para um servidor utilizando um dos seguintes protocolos suportados (HTTP, HTTPS, FTP, FPTS, FILE, POP, SMTP e entre outros). Dessa forma, vários programas podem utilizar a mesma base de código, mesmo que sejam executados em processos (threads) diferentes. Pacote de Scripts - Composto por dois Scripts Shell, responsáveis por carregar variáveis de ambiente no Shell Linux. Essas variáveis direcionam o GNU Bash e os aplicativos em execução sobre ele, para um conjunto de pastas com scripts TK (GUI Toolkit); scripts TCL (rapid prototyting, GUI and testing); scripts PERL (utilizados para customizar comportamentos internos do GIT, através do GIT Wrapper); e a pasta Engine que contem um conjunto de bibliotecas compartilhadas carregadas por programas C e C++, assim que eles são inicializados. Pacote de Configuração GIT (Etc) - Fornece um conjunto de arquivos de coordenar a execução dos seus comandos. Dentre esses arquivos é possível identificar o GIT-completion.bash, o GIT-config e o inputrc. O GIT-completion.bash habilita a capacidade de auto-completar os comandos GIT dentro do ambiente GNU bash. O GIT-config permite customizar as configurações do seu ambiente GIT, determinando aliases para comandos, color text, usernames, servidores smtp utilizados, certificados ssl, tamanhos dos pacotes enviados e recebidos, entre outras configurações. O input-rc mapea as funcionalidades do GIT e os associa com atalhos do teclado. Pacote Libs GIT - Disponibiliza um conjunto de programas independentes, escritos na linguagem C, invocados pelo programa principal GIT, anteriormente descrito no componente Shell Linux. Cada um desses programas representa comandos internos do GIT, utilizados basicamente para inicializar um repositório GIT; inserir novas versões em um repositório existente; enviar ou receber as versões de um repositório local ou remoto. Como evidenciado na Visão Estrutural do Core, temos o comando GIT-INIT, responsável por criar um diretório GIT vazio ou reinicializar um existente. Esse comando cria o diretório com a seguinte estrutura: os subdiretórios objects, refs/heads, refs/tags e templates files; e o arquivo inicial HEAD que referência o branch master. Caso o repositório que se deseja trabalhar, exista em algum servidor central, outro peer ou no próprio peer, deve-se utilizar o comando GIT-CLONE, que faz um clone do repositório através de um pull down de todos os dados do repositório apontado. Por seguinte, temos o comando GIT-ADD, que adiciona conteúdos de arquivo para o INDEX. Esse comando atualiza o objeto índex do repositório, utilizando o conteúdo encontrado no diretório de trabalho (Working Tree) e preparando-o para o conteúdo do próximo commit. Sendo assim, após efetuar modificações no diretório de trabalho, o comando GIT- ADD deve ser invocado para adicionar um novo ou modificar o arquivo índex do repositório [3]. Para auxiliar esse processo, o GIT disponibiliza o comando GIT-STATUS, responsável por mostrar o estado do índex, exibindo quais os arquivos estão aguardando o comando GIT-COMMIT. O comando GIT-COMMIT, registra as modificações no repositório. Armazena o atual conteúdo do índex em um novo commit com uma mensagem de log do usuário, descrevendo as mudanças [3]. Pacote Shared - Um conjunto de scripts prédefinidos pelo GIT, que definem templates de funcionalidades expostas para implementação publica. Como exemplo a visão estrutural do core, evidencia os templates Hooks, adicionados em cada repositório inicializado pelo GIT. E os scripts TCL GUI, utilizados pela camada superior como templates de interface gráfica. B. Visão Estrutural do Repositório A maior diferença entre GIT e qualquer outro sistema de controle de versão está na forma que o GIT trata os dados. Conceitualmente, a maior parte dos outros sistemas armazena informação como uma lista de mudanças por arquivo. Esses sistemas (CVS, Subversion, Perforce, Bazaar, etc.) tratam a informação que mantém como um conjunto de arquivos e as mudanças feitas a cada arquivo ao longo do tempo. GIT não pensa ou armazena sua informação dessa forma. Ao invés disso, considera que os dados são como um conjunto de snapshots (captura de algo em um determinado instante, como em uma foto) de um mini-sistema de arquivos. Cada vez que você salva

4 4 Figura 2. Visão Estrutural do Core ou consolida (commit) o estado do seu projeto no GIT, é como se ele tirasse uma foto de todos os seus arquivos naquele momento e armazenasse uma referência para essa captura. Para ser eficiente, se nenhum arquivo foi alterado, a informação não é armazenada novamente - apenas um link para o arquivo idêntico anterior que já foi armazenado. A Figura 3 demonstra como os componentes da camada do repositório armazenam os arquivos. Tree - O elemento em uma árvore pode ser outra árvore ou um Blob, quando representa um diretório de conteúdo. Blob - Representa um arquivo armazenado no repositório. É considerado o menor objeto do GIT. Commit - Objeto que faz referência a uma árvore e a um ou mais commits pais, assim como armazena metadados (usuário que realizou o commit, data, hora e etc). Tag - O objeto tag é muito parecido com um objeto commit contém um tagger (pessoa que cria a tag), uma data, uma mensagem e um ponteiro. A principal diferença é que um objeto tag aponta para um commit em vez de uma árvore. É como uma referência de branch, mas nunca se move ele sempre aponta para o mesmo commit, mas te dá um nome mais amigável para ele. Todos os objetos são referenciados por um SHA, um tipo de identificador que contém 40 dígitos. Se dois objetos são idênticos, então eles devem ter o mesmo SHA. Logo, se forem diferentes, devem possuir SHA distintas. Head - Objeto responsável por referenciar o último commit. Config - GIT usa uma série de arquivos de configuração para determinar comportamentos que não são padrões. Uma das primeiras atividades é configurar o nome de usuário e , facilitando dessa forma a identificação. Algumas outras configurações incluem: cor da fonte, extensões de arquivos que o usuário não quer controlar e etc. Hooks - Objeto responsável por disparar scripts personalizados quando certas ações importantes ocorrerem. Existem dois grupos desses hooks: lado cliente e lado servidor. Os hooks do lado cliente são para operações do cliente, tais como commit e merge. Os hooks do lado servidor são para operações de servidor, como recebimento de um push.

5 5 Figura 3. Visão Estrutural do Repositório Index - Antes de realizar um commit de forma definitiva, o GIT armazena os arquivos em uma área intermediária, também chamada de Staging Area. C. Visão de Implantação A Figura 4 ilustra a visão de implantação do controlador de versão distribuído GIT em uma pequena equipe de desenvolvimento de software. Essa visão está fortemente impactada pelo fluxo de trabalho adotado pela equipe. Como descrito abaixo: 1. Cada desenvolvedor (Clientes) obtém do repositório central (Servidor) a versão inicial do projeto. 2. De posse dessa versão, o desenvolvedor possui total flexibilidade para gerir o seu próprio repositório local, podendo criar branches, realizar commits e ver histórico das alterações, sem a necessidade de acessar o servidor. 3. A depender da feature que será implementada, os desenvolvedores podem efetuar a mesclagem de seus repositórios, através dos comandos pull e push. 4. Após o processo de colaboração, e com a feature finalizada, um dos dois desenvolvedores deve submeter um commit para o repositório central, finalizando dessa forma a implementação da nova feature. Diante do WorkFlow, explicitado logo acima, o GIT apresenta as características de outros dois estilos arquiteturais. O primeiro é o estilo arquitetural em camadas Client-Server, que se torna evidente logo no primeiro passo do fluxo. Onde um servidor central, contendo em si um repositório GIT, serve como principal fonte do código-base e como backup unificado do código-base modificado. O segundo estilo arquitetural claramente visível é o Peer-to-Peer, pois os clientes possuem a capacidade de colaborarem um com o outro, independente do servidor central. Para que essa troca de informações seja estabelecida, existem conectores diferentes para cada caso apresentado acima. A comunicação realizada entre os clientes e o repositório central, está baseada em conectores de protocolos de rede (HTTP, SSH, FTP e outros), através do conector curl. Diferente da comunicação estabelecida entre os clientes, baseada em um protocolo próprio, denominado GIT. Para que esse protocolo funcione o sistema GIT de cada desenvolvedor deve possuir um programa chamado GIT-Daemon, um pequeno servidor de repositórios, baseado em TCP e ouvindo na porta 9418 [5]. O GIT-Daemon fornece um protocolo de comunicação rápido, entretanto não é recomendável utilizá-lo para comunicações via Internet. Pois, ele define acesso de leitura não autenticado para os seus repositórios GIT. E a Figura 4, deixa isso em evidência, quando foi definida a utilização do protocolo GIT somente entre os PEER s que devem estar na mesma rede e protegidos por um firewall [6]. IV. IMPLEMENTAÇÃO E IMPLANTAÇÃO Como um dos requisitos primários do GIT é a eficiência, Linus Tolvards, decidiu escolher como tecnologia principal a linguagem C, pois acreditava que qualquer outra linguagem com nível de abstração elevado, como por exemplo, C++, poderia trazer consigo problemas de desempenho. Além disso, essa escolha limitou a colaboração do projeto, somente para programadores que compreendem as questões de baixo nível. Outras linguagens foram também adicionadas à imple-

6 6 Figura 4. Visão de Implantação do GIT mentação do GIT como, por exemplo, shell scripts, perl e python scripts, todas para viabilizar a comunicação do GIT com programas externos. E para garantir a portabilidade o GIT faz uso do PO- SIX, uma família de normas definidas pelo IEEE para garantir a portabilidade do código-fonte de programas de determinado sistema operacional para outro sistema POSIX. Para a instalação do GIT, é preciso ter as seguintes bibliotecas de dependências: curl, zlib, openssl e libiconv. Entretanto, como foi analisado o GIT para Windows, essas dependências já estão incorporadas no componente Shell Linux, mesmo assim serão descritas abaixo: curl Conector COTS utilizado para transferir dados com sintaxe URL, suportando diversos protocolos de comunicação (HTTP, FTP, FILE, SMTP). (Conector de comunicação) zlib Componente COTS multi-plataforma que disponibiliza funcionalidades para compressão de dados. OpenSsl Componente COTS que fornece implementações dos protocolos SSL e TLS. Também expõem funções básicas de criptografia e wrappers que permitem o uso dessa biblioteca em várias outras linguagens. Libiconv Conector COTS utilizado para realizar a conversão de uma codificação de caracteres para outra, por exemplo, converter arquivo de codificação UFT8 para ASCII. Utilizado no GIT para suportar múltiplas codificações de caracteres. (Conector de conversão) Expat Biblioteca utilizada para troca de informações entre os repositórios remotos GIT, responsável por efetuar o parse de arquivos XML. GetText Biblioteca do projeto GNU, utilizada para realizar a internacionalização do sistema GIT. Pthreads Biblioteca que implementa o padrão POSIX para threads, o qual define uma API padrão para criar e manipular threads [7]. V. DISCUSSÃO E CONCLUSÕES Conforme características demonstradas ao longo do trabalho, Linus Torvalds sempre colocou o desempenho como principal requisito do Git, impactando fortemente

7 7 nas decisões arquiteturais adotadas. Primeiramente na escolha da linguagem de programação C, que tem como ponto forte o desempenho, já que não precisa realizar invocações de funções virtuais, ao contrário do C++. Outro fator que contribuiu de forma significativa para o excelente desempenho do Git foi o fato do usuário possuir todo o histórico do projeto no repositório local, possibilitando dessa forma o trabalho off-line e diminuindo o tráfego de rede entre as operações, como por exemplo, commit e merge. Um dos caminhos para tornar o software mais rápido é ter que fazer um número menor de verificações. Por exemplo, quando o comando GIT-add é digitado, o algoritmo não varre todos seus arquivos a procura de mudanças. Realizar esta verificação em um diretório que contém muitos arquivos pode levar uma quantidade considerável de tempo. Na maioria das vezes que a comunidade de desenvolvedores do GIT caiu no dilema de usar uma biblioteca já pronta ou implementar sua própria, eles optaram pela segunda opção. Essas decisões de projeto contribuem para criação de softwares mais rápidos. Um grande exemplo de sucesso que podemos mencionar é o Google. Em vez de utilizar um banco de dados COTS, preferiu desenvolver o Google File System. Outro fator relevante que contribuiu para o sucesso do Git em relação às concorrentes foi à adoção dos estilos arquiteturais peer-to-peer e client-server, ficando a cargo do usuário escolher o melhor cenário, ou até mesmo utilizar os dois estilos em conjunto. Uma grande vantagem do estilo peer-to-peer é ser escalável em relação ao acesso a recursos, já que os repositórios estão espalhados em vários nós. Outro ponto positivo é a robustez em relação à tolerância a falha, devido às informações não ficarem centralizadas em um único servidor. Confirmando a expectativa do seu criador, o Git se apresentou como uma excelente e rápida ferramenta de controle de versão distribuído. Testes de desempenho realizados pela Mozilla apontaram que o Git é uma ordem de magnitude mais rápido que alguns sistemas de controle de versão. Obter o histórico das revisões salvas em repositórios locais resulta em duas ordens de magnitude mais rápido que obtê-los de um servidor remoto [1]. Outro aspecto positivo atualmente é o fato de possuir integração com as IDE s mais utilizadas no mercado de desenvolvimento de software, a exemplo do eclipse, netbeans e visual studio. Esse foi um dos grandes avanços das novas versões do sistema, já que inicialmente não se tinha integração com as IDE s comerciais. Atualmente é o sistema de controle de versão mais popular do mercado, possuindo um grande número de projetos que o utilizam a exemplo do eclipse, KDE, JQUERY, Android, Zend framework e etc. Apesar da portabilidade para executar no Windows, o Git apresentou uma performance menor em comparação a execução no Linux, sobretudo para comandos escritos em shell script. Esses problemas já estão sendo resolvidos com a migração de alguns códigos para a linguagem C, resultando em um ganho significativo de desempenho. Outro ponto negativo é o fato de alguns comandos não existirem na GUI do Windows, sendo necessário executálos através da linha de comando. Uma das maiores queixas da comunidade que utiliza o Git é com relação à falta de documentação técnica, especialmente sobre os padrões arquiteturais utilizados no projeto. Se este for um pré-requisito para começar a contribuir com a ferramenta, será preciso realizar uma análise diretamente no código fonte, já que existem pouquíssimos sites abordando este assunto de forma detalhada. Um dos fatores que não contribuem para adoção do Git é a curva de aprendizado muito mais acentuada se comparado com outras ferramentas de mercado. VI. REFERÊNCIAS 1. GIT. Disponível em Acessado em 30 de Maio de GIT. Disponível em Acessado em 28 de Maio de Documentation. Disponível em scm.com/book/en/git-basics-getting-a-git- Repository. Acessado em 28 de Maio de GIT Gui. Disponível em Acessado em 07 de Junho de GIT-Daemon. Disponível em Acessado em 07 de Junho de GIT-Daemon. Disponível em Acessado em 07 de Junho de POSIX Threads Programming. Disponível em Acessado em 07 de Junho de 2013.