Análise Comparativa de Sistemas de Controle de Versões com foco em Versionamento de Banco de Dados Oracle
Giovanni Vieira Bento, Lorraine Cassiano, Hélio Rubens Soares, Sônia Aparecida Santana
Centro Universitário do Triângulo (UNITRI)
Avenida Nicomedes Alves dos Santos – 38.411-106 – Uberlândia – MG – Brasil {giovannistill,lorrainecassiano,sonia.ap.santana}@gmail.com, hrubens@unitri.edu.br
Abstract. In corporate management models are imposed with a view to ensuring the integrity of the database before sharing information. Among the models will be highlighted in this article version control with the aim of comparing two tools, Version Control - Object (CVO) and Git, exposing the importance of appropriate mechanisms to establish and compose combinations of versions. The results show that when it comes to versioning database, the CVO stands out positively.
Resumo. Em ambientes corporativos são impostos modelos de gerenciamento com intuito de assegurar a integridade da base de dados perante o compartilhamento das informações. Dentre os modelos, será evidenciado neste artigo o controle de versão com o objetivo de comparar duas ferramentas, Controle de Versão - Objeto (CVO) e Git, expondo a importância dos mecanismos adequados para estabelecer e compor combinações de versões. Os resultados apontam que se tratando de versionamento de banco de dados, o CVO se destaca positivamente.
1. Introdução
Algumas aplicações corporativas demandam da necessidade de acesso concorrente às informações mantidas em seu banco de dados. Por exemplo, o desenvolvimento da parte de análise de crédito do cliente em uma empresa de telecomunicação pode ser dividido entre vários membros de uma equipe, onde cada membro deve desenvolver uma parte do objeto de banco ou interface do sistema. Assim, um mesmo plano de informação (PI) do banco de dados (BD) seria atualizado por vários usuários de forma simultânea. Com isso, um
sistema de BD deve oferecer mecanismos que garantam a consistência do banco quando vários usuários leem e alteram os dados de forma concorrente.
Quando um banco de dados é versionado resolve-se parte de um problema, pois assim não se perde as estruturas do banco, bem como a lógica de negócios encontrada nas triggers, functions e procedures. No entanto, a utilização das ferramentas auxiliadoras no controle de versão não substitui o papel do DBA (Data Base Administrator). A ideia é que elas contribuam com melhorias na qualidade e eficiência do trabalho de cada um.
Diante destas situações, este artigo tem como objetivo analisar as principais funcionalidades apresentadas pelas ferramentas CVO e Git, sendo que essa análise pode ajudar na escolha e tornar uma opção de ferramenta em projetos de softwares envolvendo banco de dados.
Na seção 2 foi feita uma revisão bibliográfica contendo conceitos de tipos de versionamento de banco de dados e um pouco sobre cada ferramenta. Na seção 3 foram feitos testes que originaram um comparativo, utilizando critérios criados pelo RUP (Rational Unified Process) para a escolha de ferramentas de suporte ao desenvolvimento de softwares. Os resultados mostraram que se tratando de versionamento de banco de dados, o CVO se destaca positivamente demonstrado na seção 4. Finalmente, na seção 5 serão apresentadas as conclusões obtidas ao final deste artigo.
2. Base Conceitual
Há tempos os Bancos de Dados (BDs) não são tratados apenas como um repositório. As organizações vêm criando aplicações que têm vários pontos em BDs. Ao olhar o desenvolvimento dos softwares, percebe-se a utilização de práticas e ferramentas de versionamento, o que na maioria das vezes não acontece com o banco de dados, podendo ser por motivos, por exemplo, culturais. Empresas trabalham divididas em equipes, onde o analista de desenvolvimento não faz parte do mesmo grupo que o analista de banco de dados, em alguns casos, cada um trabalhando em um paradigma diferente.
De acordo com Prado (2006)
Muitos SCVs (Sistemas de Controle de Versões) têm sido desenvolvidos para gerenciar o histórico das versões de software e atividades humanas associadas com a intenção de produzir software de maior qualidade e suportar trabalho em equipe.
Estes sistemas de versionamento servem também para equipes que possuem apenas uma pessoa, pois a documentação dos códigos fonte de um software contribui para entrega de um sistema de maior qualidade.
2.1. Versionamento de Esquemas
O usuário é quem define como será a versão do esquema, ou seja, não basta alterar os dados ou o próprio esquema para que uma nova versão seja definida. O Sistema de Gerenciamento de Banco de Dados (SGBD) deve ser capaz de acessar os dados em qualquer versão.
Para alterar os dados de um esquema é necessário saber qual o tipo de versionamento foi adotado. Se for o versionamento parcial, somente serão alterados os dados da versão atual. Caso tenha sido o total, qualquer uma das versões do banco poderá ter seus dados alterados (RODRIGUES, 2011).
2.1.1 Versionamento em Banco de Dados Orientado a Objetos (BDOO) Pinheiro (2012) aponta
Podem ocorrer situações em determinados sistemas em que seja fundamental o uso de uma versão anterior e por isso a utilidade de armazená-la. Ao versionar um objeto ocorre mudanças tanto na estrutura quanto no estado. Cria-se um tipo de raiz que aponta para todas as versões e é fundamental manter a versão atual assim que o objeto for modificado (CARVALHO, 2011).
2.1.2. Versionamento em Banco de Dados Geográficos (BDGeo)
O versionamento em BDGeo trata da representação do mesmo em cópias lógicas de algumas tabelas sobre uma determinada visão ou por um período de tempo, ou seja, não ocorre a duplicação dos dados. Em caso de conflito entre duas versões, gera-se outra representação dos dados contendo as propriedades daqueles conflitantes, mostrando com isso que não há interferência entre elas.
O gerenciamento de versão em um banco de dados orientados a objeto consiste em ferramentas e construções que automatizam ou simplificam a construção e a organização de versões ou configurações. Sem essas ferramentas, caberia ao usuário organizar e manter as versões.
O progresso do BDGeo é representado pela estrutura lista, onde uma versão deriva de outra e possui apenas uma sucessora. Cada versão que possui mais de uma sucessora é representada pela estrutura de árvore e se, além disso, possuir mais de uma predecessora é representado pelos grafos (BARBOSA, 2008).
2.1.3 Versionamento de dados em bancos de dados relacionais
Para realizar o controle de versão em banco de dados relacionais depende das camadas, ou seja, divisões do BD fragmentadas em motor de banco de dados – parte do SGBD que é o elo entre os programas do SGBD e os dados (THOMÉ, 2011). Procedimentos de usuários armazenados no BD que interceptam as requisições de atualização ou a camada que fica a cargo do programador da aplicação. Nos casos em que o versionamento é feito junto ao motor de banco dados não é exigido alteração no esquema. Nas demais, é necessário adicionar colunas e/ou tabelas contendo metadados referentes aos versionamento. Metadados que de acordo com Lourenço (2007), “são habitualmente definidos simplesmente como dados descrevendo outros dados”. Para esses casos são três práticas usadas: esquema único, espelhamento e tabela polimórfica.
Esquema único é o nome dado à categoria onde se altera o esquema de cada tabela adicionando uma coluna com o controle de versão dela e modificando a chave primária para conter também essa nova coluna de controle. O espelhamento faz uma cópia da tabela original com uma coluna a mais para armazenar a versão, a essa cópia dá-se o nome de espelho e então os dados são alterados na tabela original. Na tabela polimórfica, cria-se apenas uma tabela, chamada de tabela de versões, para armazenar todas as tabelas versionadas (DUARTE, 2012).
2.2. Git
Durante a criação do sistema operacional Kernel Linux, Linus Torvalds, criador do Kernel Linux, observou a necessidade de criar uma ferramenta open source que pudesse realizar o controle de versões dos códigos fontes de diversos projetos incluindo códigos de banco de dados. Assim surge o Git
Version, uma aplicação distribuída capaz de versionar projetos com velocidade e eficiência.
Dentre as características do Git, existe o suporte para desenvolvimento linear, ou seja, uma metodologia de programação onde são alteradas partes distintas do sistema ao mesmo tempo com o intuito de mesclá-las ao final do processo (SILVERIO, 2013).
O Git contém uma forma diferente dos demais sistemas de controle de versão para manipular os dados. A cada mudança de um projeto versionado pelo Git, é realizado um snapshot (tirada uma foto) dos objetos armazenados. Por exemplo, se em algum arquivo não houve alteração, o sistema não armazena o arquivo novamente, apenas acrescenta um “link” para o objeto anterior idêntico ao armazenado anteriormente. Já os outros sistemas de controle de versão tratam as mudanças feitas nos dados ao longo do tempo como um conjunto de arquivos (MARTINHO; MUNIZ, 2013).
Inicialmente o Git armazena o conteúdo em arquivos com extensão “sha”, para que possa gerar um número de revisão do arquivo. Tipo de valor que é utilizado na identificação interna simplificados em outros dois tipos, loose objects e packed objects. Os arquivos do tipo loose objects são mais simples e armazenados no disco num único arquivo. Os packed objects são mais sofisticados e cada versão é armazenada em objetos separados (ZANATTA; SANTOS, 2012).
Trabalhando em modo terminal o Git pode ser considerado um pouco complicado no início, porém com tempo de experiência a configuração se torna mais fácil e simples.
O arquivo .gitconfig armazena as configurações gerais do sistema Git. Este arquivo fica armazenado no diretório home do usuário que está realizando as configurações. Existem duas formas de configuração, de forma mais simples utilizando o comando git config que realiza as configurações automáticas, ou da maneira mais complexa que é alterando o arquivo de configuração manualmente. Dentro dos critérios de utilização básica do Git existem os comandos de instalação, iniciação e manipulação de repositório, modificações e clonagem de um repositório remoto. Pelo terminal, entrar na pasta do projeto
a ser iniciado e utilizar o comando $ git init. Este comando cria um diretório invisível, contento todos os arquivos necessários para o repositório. Para adicionar arquivos em um projeto no repositório utilizar o comando $ git add. E para visualizar o status daquilo que foi incluído no projeto deve-se executar o comando $ git status conforme Figura 1. Feito estes procedimentos resta o comando de $ git commit, assim é enviada uma alteração para o Sistema Git (CHACON, 2009).
Figura 1 - Utilizando o Git Bash
2.3. Controle de Versão – Objeto
A CVO é uma aplicação que foi desenvolvida em linguagem Delphi com banco de dados Oracle. O intuito do aplicativo é buscar com agilidade backup do código dos objetos sem a necessidade de fazer o restore do banco utilizando o aplicativo RMAN – ou Recovery Manager. Sendo assim, de acordo com Rezende (2011) o RMAN serve para “auxiliar os DBAs nas tarefas do dia-a-dia referente à execução de cópias de segurança dos arquivos do banco de dados garantindo assim a recuperabilidade do banco de dados em caso de falha”. O que custaria demanda de tempo e espaço em disco.
2.3.1. Banco de Dados versionado com CVO (Controle de Versionamento – Objeto)
O DBA recebe uma planilha contendo os nomes dos objetos a serem atualizados no ambiente de Produção informando o sistema desta atualização. Antes disso, é feita de forma manual o controle dos conflitos.
A equipe de qualidade realiza em cada objeto uma comparação da versão que foi homologada com a versão que está em produção. Caso tenha na primeira um projeto que não será atualizado, é guardando um backup do mesmo e então uma nova versão compilada no ambiente de homologação contendo apenas o projeto que será atualizado. Nos testes de regressão realizado no ambiente de pré-produção é garantido que nenhum projeto que não deverá ser atualizado esteja ainda no ambiente, bem como se a retirada do mesmo impactou em algum projeto que será então atualizado.
Baseado nessas informações, utilizando o CVO, o DBA seleciona o sistema e o ambiente a ser atualizado. Os objetos são importados na ferramenta e automaticamente é informado se os objetos existem ou não no ambiente de origem e destino. Caso o objeto não existir no sistema de origem o sistema não habilita o botão “Gerar DDL”.
O sistema “Controle de Versão – Objeto” cria automaticamente o diretório onde o arquivo e o backup da DDL são gravados, conforme Figura 1. Exemplo: em destaque no caminho a seguir demonstra a data corrente
(dia-mês-ano_hora/minuto). Exemplo:
“\\filebkp\suporte$\GBD\OMU\OMU_2013\VANTIVE\OMU_SIMULADO_15-05-2013_1004”.
Ao término da geração da DDL o aplicativo executa automaticamente a rotina de atualização dos arquivos gerados no sistema subversion, conforme mostrado também na Figura 2. O subversion permite a recuperação de todas as versões dos dados guardados em arquivos e/ou diretórios, além de uma visualização de todo o histórico de alterações (SUSSMAN et al., 2007). Com a gravação do backup no subversion é possível ter o controle de recuperação garantido, pois em caso de alguma falha basta executar os backups garantindo assim que o BD fique estável como antes do inicio da atualização.
Após os objetos gravados no subversion, selecionando a DDL gerada utilizando uma ferramenta de desenvolvimento Oracle opcional, o DBA executa a atualização dos objetos no ambiente de destino. Como a tarefa é realizada apenas por um DBA, não é possível haver uma mesma versão conflitando com outra, além do que toda versão de um mesmo objeto terá a data da atualização
como diferencial entre as versões, com isso o CVO não precisa se gerenciar as transações.
Figura 2 - Arquivo DDL e Subversion
É válido ressaltar que o controle de concorrência dos objetos a serem atualizados é feito de forma pessimista no ambiente de desenvolvimento, ou seja, os analistas avisam aos outros, através de um grupo de email, sobre a alteração de um determinado objeto por um período de tempo. Com isso o objeto só ficará disponível para outro, quando o termino do prazo chegar.
A ferramenta possui a funcionalidade de pesquisa de versões de objetos filtrando a busca por nome de objeto ou pela data de atualização. No resultado são disponibilizados os diretórios do subversion onde estão salvas as DDLs das versões anteriores dos objetos filtrados, conforme Figura 3. Com isso, é possível ter acesso a qualquer versão de qualquer objeto, garantindo o retorno do ambiente a qualquer ponto anterior, em caso de necessidade.
Diretório e arquivo DDL
Figura 3 - Funcionalidade de Pesquisa
3. Comparação entre os Sistemas CVO e Git
Para o estudo de caso serão considerados dois ambientes: desenvolvimento (CRMDBASE) e produção (CRMPBASE). No ambiente de desenvolvimento são criados os objetos de banco, desenvolvidas as regras de negócio e se necessário à alteração de códigos existentes. Produção é o ambiente final. Conforme a Figura 4 ilustra a migração dos objetos de ambiente para ambiente. Diretório Pesquisar Sistema Ambiente Digitar o que pesquisa Pesquisar Resultado
Figura 4 - Migração de Ambiente CRMDBASE CRMPBASE
A Análise comparativa feita neste artigo utilizando o CVO e o Git se justifica, pois ambos foram adquiridos gratuitamente, apresentam qualidade; e também por terem peculiaridades que garantem um melhor controle de versão, como por exemplo: o emprego de um repositório centralizado e da técnica de copy-modify-merge, onde a cada modificação seguida de um commit, tornam disponíveis instantaneamente para os usuários as informações, simplificando assim a maneira de realizar o controle de versões (CARNEIRO, 2007).
A forma como é realizado o histórico de versões no repositório é uma característica que diferente as ferramentas. O Git considera os dados como um conjunto de versões de um pequeno sistema de arquivos. Após salvar ou realizar um commit no projeto, o Git realiza uma espécie de fotografia dos arquivos e guarda uma referência dessa foto. Caso não ocorra nenhuma modificação apenas uma referência é criada para a versão anterior, não sendo preciso sofrer nenhuma alteração (BORGES, 2012). Já no CVO as informações de alterações são armazenadas em uma lista por arquivo, ou seja, mantém o que não foi alterado como um conjunto de arquivos mais as alterações feitas a cada arquivo ao longo do tempo.
3.1. Definição dos critérios de comparação
Conforme a Tabela 1 os critérios adotados foram baseados em uma das atividades apontadas pelo RUP 1 para a fase de iniciação do projeto, a qual presume selecionar e adquirir ferramentas de suporte necessário ao desenvolvimento do projeto.
Tabela 1 – Definições dos critérios utilizados na análise
Critérios Descrição
Características e funções A funcionalidade fornecida pela ferramenta. Integração com Oracle O grau de integração com o banco de dados
Oracle.
Aplicabilidade No processo de desenvolvimento até onde oferece suporte.
Extensibilidade Possibilidade de configurar e personalizar.
Suporte a equipe Possibilidade de dar suporte a uma equipe de
usuários que está em espaços diferentes. Usabilidade Facilidade em usar e aprender.
Maturidade Nível de maturidade. Mesmo com boa reputação, algumas empresas não investiriam em uma versão 1.0
Suporte a configurações Suporte para instalar, configurar e usar a ferramenta.
Treinamento Treinamento disponível.
Através de avaliações comparativas de modelos aplicados pela gerência de configuração em projeto de softwares, Cia (2006) e Oliveira et al. (2006), definiram e utilizaram alguns itens da Tabela 2 para o método características e funções.
Tabela 2 – Definições das características e funções comparadas Características e
funções
Descrição
Commit atômico Ou realiza todas as atualizações ou nenhuma. Diferença de arquivos Controle de arquivos em diferentes formatos.
Mudanças Informar qual item está em alteração por alguém da equipe.
Permissões Cada integrante da equipe pode ter permissões diferenciadas.
Suporte Perceber diferentes versões de arquivos que constituem uma distribuição e recuperar a mesma. 4. Apresentação e Análise dos Resultados
Os testes de instalação e utilização das ferramentas foram realizados em ambientes Linux e Windows. A documentação mostra que o Git também é compatível com Mac OS X e Solaris. Nos testes de merge, ambas as ferramentas possuem tal funcionalidade. Já a renomeação dos arquivos o Git, ao contrário do CVO, permite a renomeação dos arquivos.
Para os testes das ferramentas foram configurados os sistemas CVO e Git em um mesmo servidor que tem como sistema operacional Red Hat Enterprise Linux Server release 5.8 (64-bit) e os clientes em ambientes
Windows e uma Máquina Virtual com o Oracle Linux conforme a Figura 6 e 7, ambos com o banco de dados Oracle 11g instalado e configurado.
Figura 5 - CVO no Windows (esquerda) e CVO no Linux (direita)
Figura 6 - Git no Linux (esquerda) e Git no Linux (direita)
Através da aplicação PL-SQL Developer foi desenvolvido o projeto de banco de dados contendo objetos como, procedures, packages, functions. Conforme ilustra a Figura 9, a criação do objeto FC_BUSCA_PARAMETRO.
Nos testes realizados a Figura 10 mostra que o CVO cria no repositório, automaticamente, por meio de um clique do botão da interface, o arquivo que contém os códigos fonte dos objetos do banco de dados.
Figura 8 - Criando repositório no CVO
Já o Git necessita da extração dos objetos para um arquivo no diretório local e através de comandos nativos da aplicação, as alterações são submetidas por meio de um comando (git commit). O CVO grava as modificações, porém o armazenamento somente é realizado caso não haja nenhuma ocorrência ou falha durante a gravação dos dados, garantindo a atomicidade do commit conforme ilustra a Figura 11.
Enquanto o CVO armazena apenas as DDLs extraídas dos objetos em formato .sql, o Git armazena esse tipo de formato e outros como: imagens, músicas, textos, etc. A Figura 12 ilustra os arquivos quanto ao âmbito de mudanças, as duas ferramentas demonstram eficiência; ficam gravadas no servidor todas as operações de commit e check-out realizados durante o teste. Desta forma o gestor do projeto consegue monitorar quem, quando e o que foi modificado.
Figura 9 - Comando git commit
Figura 10 - Histórico de Objetos no Git
Já o controle de acesso pode ser definido com perfis temporários, gerenciá-los com o sistema de permissão de arquivos do sistema operacional que o seu servidor roda, isso no Git. Se o acesso for liberado ao CVO, o usuário é capaz de realizar tanto leitura quanto escrita. Com relação ao suporte, ambos disponibilizam ao usuário a identificação das versões para realizar a recuperação no repositório.
A comparação das características e funções realizada na Tabela 3, o Git apresentou um melhor resultado, atendendo a quase todos os itens analisados.
Tabela 3 – Comparativo do método: características e funções Características e
Funções
CVO Git
Commit atômico Possui Não Possui
Diferença de arquivos Não Possui Possui
Mudanças Não Possui Possui
Permissões Não Possui Possui
Suporte Possui Não possui
A integração com o banco de dados Oracle também não apresenta problemas. Contudo o CVO possibilitou uma melhor aplicabilidade no processo de localização dos objetos do BD, através da interface de consulta.
Figura 11 - Interface de consulta de Objeto
Por apresentarem características próprias, a extensibilidade não é aplicada por eles, contudo ambos disponibilizam seus códigos fontes para que seja possível o usuário oferecer sua contribuição de melhora. Aplicando as características de cliente/servidor, os testes apontaram que ambos funcionam neste tipo de ambiente, assim pode-se trabalhar com uma equipe geograficamente distribuída.
Mesmo o Git possuindo configurações em linha de comando, os dois sistemas apresentam boa usabilidade aplicados ao banco de dados Oracle,
porém o CVO é o candidato mais forte em questão de interface com o usuário e se adéqua exclusivamente ao versionamento de banco de dados. Analisando as versões (CVO 2.0 e Git 1.8.3), deduz uma maturidade para uso de ambas.
Ambos possuem disponibilizados para suporte e configurações, documentos necessários que possibilitam a utilização de suas funções. Nenhuma das ferramentas oferece treinamento, porém é possível encontrar tutoriais na internet do Git e o criador da ferramenta CVO também disponibiliza o tutorial da mesma para quem necessitar de seu uso.
A comparação realizada na Tabela 4 demonstra que o CVO atende um pouco mais os critérios adotados. Apesar de atender parcialmente ao método características e funções, que é de suma importância para um bom desempenho do sistema em projetos de software, o CVO atende totalmente ao método Integração com Oracle, que para o foco do artigo de versionamento em banco de dados é o mais adequado.
Tabela 4 – Comparativo dos critérios estabelecidos
Critérios CVO Git
Integração com Oracle Atende totalmente Atende parcialmente Aplicabilidade Atende totalmente Atende totalmente Extensibilidade Não Atende Não Atende
Suporte a equipe Atende totalmente Atende totalmente Usabilidade Atende totalmente Atende
parcialmente Maturidade Atende totalmente Atende totalmente Suporte a Configurações Atende totalmente Atende totalmente
Treinamento Não atende Não atende
5. Conclusão
O controle de versão é de suma importância para o monitoramento das alterações feitas nos projetos. Realizar o controle de versão do banco de dados faz com que aplicação e banco caminhem lado a lado para garantir a qualidade do projeto. Os objetos dessa pesquisa, CVO e Git, possuem qualidade e
eficácia na proposta de realizar o controle de versão de banco de dados. A comparação feita neste artigo foi baseada nos ensinamentos definidos pelo RUP, com o objetivo de validar quais itens cada ferramenta contribuiria para um melhor controle de versão ser feito com qualidade.
Através desse artigo foi possível observar que o CVO apresentou uma pequena vantagem no que diz respeito à usabilidade e a integração com o Oracle, ou seja, em se tratando de controle de versão de banco de dados seria a melhor opção. Como as ferramentas estão em constante desenvolvimento pode ser que a falta de recursos ou falha nos mesmos sejam solucionadas e adaptadas.
As percepções obtidas neste artigo com o uso da ferramenta Git podem ser complementadas com trabalhos futuros que possibilitem uma comparação com o desenvolvimento de uma interface que se integre ao Git, assim como o CVO faz a integração com o subversion, já que a pesquisa apenas utilizou o Git a partir de fontes já gerados por outras ferramentas. Outra proposta é o desenvolvimento de um módulo para controle de versão das tabelas e seus dados.
Referências
BARBOSA, Leandro Rodrigues. Integração entre sistema de informação geográfica e sistema de projeto de redes de distribuição. São Paulo 2008. Disponível na internet. http://www.teses.usp.br/teses/disponiveis/3/3143/tde-30052008-140230/pt-br.php. 20 de maio de 2013.
BORGES, Marcos Eduardo. Introdução ao Git – Conceitos básicos. São Paulo 2012. Disponível na internet. http://www.borges-solutions.com/introducao-ao-git-conceitos-basicos/. 28 de julho de 2013.
CARNEIRO, Adriano Nântua. Um guia para controle de versão de Projeto de Software. Pernambuco 2007. Disponível na internet.
http://tcc.ecomp.poli.br/20072/Adriano%20N%C3%A2ntua.pdf. 29 de julho de 2013.
CARVALHO, Guilherme Cantuária de. Sistema de Banco de Dados Orientados a Objetos. São Paulo 2011. Disponível na internet.
http://www.fatecsp.br/dti/tcc/tcc0002.pdf. 11 de abril de 2013.
CHACON, Scott. Pro Git - The entire Pro Git book. New York 2009. Disponível na internet. https://github.s3.amazonaws.com/media/progit.en.pdf. 28 de julho de 2013.
CIA, Thaís Miranda. Modelo de avaliação do processo de gerência de configuração de software. São Carlos 2006. Disponível na internet. http://www.teses.usp.br/teses/disponiveis/55/55134/tde-24082006-163201/pt-br.php. 22 de julho de 2013.
DUARTE, Gustavo Luiz. Metadados para reconciliação de transações em banco de dados autônomos. São Paulo 2012. Disponível na internet. http://www.teses.usp.br/teses/disponiveis/45/45134/tde-27082012-153008/pt-br.php. 18 de abril de 2013.
LOURENÇO, Cíntia de Azevedo. Metadados Digitais: revisão bibliográfica da evolução e tendências por meio de categorias funcionais. Belo Horizonte 2007. Disponível na internet. http://cintialourenco.eci.ufmg.br/downloads/466-986-1-PB.pdf. 08 de agosto de 2013.
MARTINHO, Marcus, MUNIZ, Elson. GIT SCM: Sistema de Controle de Versionamento Distribuído. Manaus 2013. Disponível na internet.
http://www.tjam.jus.br/index.php?option=com_content&view=article&id=4032
%3Agit-scm-sistema-de-controle-de-versionamento-
distribuido&catid=344%3Asds-artigos-cientificos-e-tecnologicos&Itemid=455&showall=1. 28 de julho de 2013.
OLIVEIRA, Susana Brunoro C., TANAKA, Astério K., VIANNA, Dalessandro S. Avaliação de ferramentas para controle automatizado de versões de
artefatos de requisitos de software. Rio de Janeiro 2006. Disponível na internet.
http://wer.inf.puc-rio.br/WERpapers/pdf_counter.lua?wer=WER06&file_name=susana_oliveira. pdf. 25 de julho de 2013.
PINHEIRO, Marcel Borges. Banco De Dados. Cuiabá - Mato Grosso 2012. Disponível na Internet. http://www.trabalhosfeitos.com/ensaios/Banco-De-Dados/416047.html. Acessado em 20 de maio de 2013.
PRADO, Lucio Moratelli. Visualization of Version Control Information. Florianópolis 2006. Disponível na internet.
https://projetos.inf.ufsc.br/arquivos_projetos/projeto_546/resumo2.doc. 17 de abril de 2013.
REZENDE, Ricardo. Automatizando um backup com RMAN - Parte 2. Revista SQL Magazine. Edição 85 - 2011.
RODRIGUES, Renan Bet. XVERSIONING - Uma Ferramenta para
versionamento de esquemas XML. Joinville 2011. Disponível na internet.
http://www.pergamum.udesc.br/dados-bu/000000/000000000012/000012D9.pdf. 17 de maio de 2013.
SILVERIO, Henrique. Introdução ao controle de versões com Git. São Paulo 2013. Disponível na internet.
http://blog.henriquesilverio.com/git-github/introducao-ao-controle-de-versao-com-git/. 29 de Julho de 2013. SUSSMAN, Ben Collins, FITZPATRICK, Brian W, PILATO, C. Michael. Controle
de Versão com Subversion. California, USA - 2007. Disponível na internet. http://svnbook-pt-br.googlecode.com/svn/snapshots/1.4/svn.intro.whatis.html. 16 de maio de 2013.
THOMÉ, Luciana Ferraz. Introdução a banco de dados. Rio de Janeiro 2011. Disponível na internet. www.ic.uff.br/~ferraz/BDI/BD/Bd98_11.doc. 08 de agosto de 2013.
ZANATTA, Bruno, SANTOS, Gustavo Alexandre Sousa. Comparando os sistemas de controle de versão distribuídos Git e Mercurial. Revista Engenharia de Software Magazine. Edição 54 – 2012.
