Baixar este arquivo PDF - Unitri - Ensino em Tecnologia de Qualidade

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, [email protected]
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
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.
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 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 diaa-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 (diamê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.
Diretório e
arquivo DDL
Subversion
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.
Pesquisar
Ambiente
Digitar o que
pesquisa
Sistema
Resultado
Pesquisar
Diretório
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.
CRMDBASE
CRMPBASE
Figura 4 - Migração de Ambiente
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
1
http://www.wthreex.com/rup/portugues/index.htm
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 Descrição
funções
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.
Figura 7 – Objeto do banco 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 CVO
Git
Funções
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/tde30052008-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-aogit-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-24082006163201/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-27082012153008/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/466986-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-versionamentodistribuido&catid=344%3Asds-artigos-cientificos-etecnologicos&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.pucrio.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-DeDados/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/dadosbu/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/gitgithub/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.