You are on page 1of 20

UNIVERSIDADE DO SUL DE SANTA CATARINA GILMAR REOLOM PUPO

GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE: BENEFÍCIOS DO CONTROLE DE VERSÕES DISTRIBUÍDO PARA PROJETOS DE SOFTWARE

Palhoça 2011

GILMAR REOLOM PUPO

GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE: BENEFÍCIOS DO CONTROLE DE VERSÕES DISTRIBUÍDO PARA PROJETOS DE SOFTWARE

Relatório apresentado ao Curso Tecnologia em Gestão da Tecnologia da Informação, da Universidade do Sul de Santa Catarina, como requisito parcial à aprovação na disciplina de Estudo de Caso.

Orientador: Prof. Horácio Dutra Mello

Palhoça 2011

GILMAR REOLOM PUPO

GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE: BENEFÍCIOS DO CONTROLE DE VERSÕES DISTRIBUÍDO PARA PROJETOS DE SOFTWARE

Este trabalho de pesquisa na modalidade de Estudo de Caso foi julgado adequado à obtenção do grau de Tecnólogo em Gestão da Tecnologia da Informação e aprovada em sua forma final pelo Curso Superior de Tecnologia em Gestão da Tecnologia da Informação da Universidade do Sul de Santa Catarina.

Palhoça, 29 de Maio de 2011.

Prof. e orientador Prof. Horácio Dutra Mello, Ms. C. Universidade do Sul de Santa Catarina

AGRADECIMENTOS

Agradeço a comunidade open source que é o motor para inovações e fonte de conhecimento livre advindo de grandes mentes doadoras. Agradeço a Deus por ter-nos dado tal comunidade em modelo Bazar e não uma complexa catedral. Agradeço a Scott Chacon pela vasta documentação sobre DVCSs compartilhada. Agradecemos ao meus professores pela dedicação e paciência . Agradeço a todos que involuntariamente ou voluntariamente me ajudaram na conclusão desse trabalho, suportando ou incentivando a produção deste.

RESUMO

Este projeto sugere melhorias no modelo de versionamento de arquivos de um projeto de software e aponta problemas enfrentados no uso de sistemas de controle de versão centralizados. O estudo de caso realizado visualizou a aplicabilidade da adoção de um sistema de controle de versão distribuído no processo de desenvolvimento de software e a importância que a cultura e as comunidades de desenvolvedores possuem no processo evolutivo do conhecimento da indústria de software. As conclusões indicaram que nas empresas estudadas, os sistemas de controle de versão distribuído reforçaram a interação entre os desenvolvedores e incentivam a adoção de melhores práticas de engenharia de software, otimizam o uso de recursos computacionais e oferecem soluções a problemas enfrentados no dia a dia do desenvolvimento de software e também que a adoção de um sistema de controle de versão distribuído pela Gerência de Configuração de Software pode ser simples desde que reconhecido como um novo paradigma.

Palavras-chave: Desenvolvimento de Software; Engenharia de Software, Sistema de controle de versão.

Sumário
1 INTRODUÇÃO.....................................................................................................................7 2 TEMA.....................................................................................................................................8
2.1 PROBLEMA......................................................................................................................................................8 2.2 JUSTIFICATIVA...............................................................................................................................................8

3 OBJETIVOS..........................................................................................................................9
3.1 OBJETIVO GERAL..........................................................................................................................................9 3.2 OBJETIVOS ESPECÍFICOS.............................................................................................................................9

4 PROCEDIMENTOS METODOLÓGICOS.....................................................................10
4.1 CAMPO DE ESTUDO.....................................................................................................................................10 4.2 INSTRUMENTOS DE COLETA DE DADOS...............................................................................................10

5 APRESENTAÇÃO E ANÁLISE DA REALIDADE OBSERVADA.............................11 6 PROPOSTA DE SOLUÇÃO DA SITUAÇÃO PROBLEMA.........................................13
6.1 Proposta de melhoria para a realidade estudada...............................................................................................13 6.2 Resultados esperados........................................................................................................................................13 6.3 Viabilidade da proposta....................................................................................................................................13

7 CONSIDERAÇÕES FINAIS.............................................................................................14 REFERÊNCIAS....................................................................................................................15

1

INTRODUÇÃO

O desenvolvimento de software evolui em ritmo acelerado e muitos problemas frequentemente enfrentados são solucionados a cada dia. Problemas relacionados ao rastreamento de alterações no desenvolvimento de um software foram a anos solucionados com a engenharia de controle de mudanças. O desenvolvimento de software de modo cooperativo resolveu problemas de conflito de versões diferentes de um arquivo com a utilização de sistemas de controle de versão. Em evolução mais recente, problemas foram solucionados com a utilização de sistemas de controle de versão distribuídos, e é de alguns dos problemas resolvidos com esta evolução que este projeto aborda.

2

TEMA

Um sistema de controle de versão, em seu conceito primordial, além de ser um um software para gerenciar diferentes versões de um documento qualquer, é o processo de guardar o histórico de alterações de diferentes arquivos. Um grande número de equipes de desenvolvimento de softwares utilizam este conceito de versionamento para o código fonte, e em organizações com processos certificados de maturidade, a utilização do versionamento é parte da Gerência de Configuração de Software (SCM). O modelo de sistema de controle de versões tradicional e mais utilizado é o centralizado. Projetos importantes no cenário computacional utilizam um modelo sistema de controle de versões distribuído, com processos mais inteligentes, dentre eles o projeto do Kernel do Linux, muitos softwares open source e softwares proprietários. O Tema a ser estudado em meu projeto é: Benefícios do controle de versões distribuído (DVCS) para projetos de software

2.1

PROBLEMA

O problema a ser resolvido é a incompreensão do modelo distribuído, impedimento da adoção de um modelo mais inteligente, e livre de problemas comuns aos sistemas de controle de versão centralizados ou ainda o questionamento quanto aos benefícios de tal adoção. Assim: Quais os benefícios do controle de versões distribuído (DVCS) para projetos de software?

2.2

JUSTIFICATIVA

A escolha desse tema virá contribuir, em certa medida, para melhoria do processo de desenvolvimento de software, utilizando engenharias possíveis para desenvolvimento distribuído e novas maneiras de interação em equipes e também em comunidades virtuais.

3 OBJETIVOS

3.1 OBJETIVO GERAL

Este trabalho tem como objetivo apresentar possibilidades e benefícios de uso de um Sistema de Controle de Versões Distribuído (DVCS - Distributed Version Control System) e sugerir a adoção do modelo distribuído como transformação de parte do processo de desenvolvimento de projetos de software, esclarecendo diferenças comumente vistas como meras modernizações de um sistema de controle de versões de código fonte.

3.2 OBJETIVOS ESPECÍFICOS

Identificar resultados positivos de uso de Controle de Versões em Projetos de Software; Identificar problemas enfrentados pelos desenvolvedores e pela Gerência de Configuração em empresas que adotam um Sistema de Controle de Versões Centralizado ; Identificar benefícios resultantes da adoção de um Sistema de Controle de Versões Distribuído;

4 PROCEDIMENTOS METODOLÓGICOS

4.1

CAMPO DE ESTUDO

Rauen (2002) define estudo de caso como um estudo profundo de um ou de poucos objetos, que busca retratar a realidade de forma completa e profunda, de modo a permitir o seu amplo e detalhado conhecimento. O tipo de pesquisa escolhido para o desenvolvimento deste projeto pode ser classificado como abordagem exploratória, a qual tem como objetivos gerar conhecimentos para aplicação prática e dirigidos à solução de problemas específicos, e foi estruturada por meio de uma revisão bibliográfica sobre o assunto e executada por coleta de dados pelo método de entrevista, com o uso de questionário estruturado aplicado a uma pequena amostra de empresas que passaram pelo processo de implementação de sistema de controle de versões. A metodologia para elaboração do trabalho consiste das seguintes etapas: a) Levantamento teórico; b) Definição das necessidades de melhoria no processo de versionamento do código fonte em projetos de software em fábricas de software;

4.2 INSTRUMENTOS DE COLETA DE DADOS

Os instrumentos de coleta de dados adotados neste trabalho são descritos no quadro a seguir.

Instrumento de coleta de dados

Universo pesquisado Serão entrevistados 5 líderes de

Finalidade do Instrumento A finalidade destas entrevistas é mapear os problemas relacionados ao uso do sistema de controle de versões e benefícios adquiridos com a mesma utilização, fazendo comparação entre os resultados de engenharias diferentes.

Entrevista

equipes de desenvolvimento de software, sendo que 3 destes líderes atuam em empresas Brasileiras, utilizando Sistema de controle de versões centralizado e 2 destes líderes atuam em empresas Estadunidenses e utilizam Sistema de

controle de versões distribuído Serão utilizados as documentações O objetivo é entender a engenhaDocumentos para desenvolvedores de projetos de software livre que utilizam Sistema de controle de versões, manuais oficiais dos próprios sistemas de controle de versões, e livros didáticos sobre o assunto. Também serão utilizadas páginas web relatando casos de utilização, problemas e benefícios em determinada implantação. Quadro 1- Instrumento de coleta de dados. Fonte: Unisul Virtual, 2007. ria e possibilidades das tecnologias de versionamento.

5 APRESENTAÇÃO E ANÁLISE DA REALIDADE OBSERVADA

A empresa Brasileira Empresa-A está no mercado de aplicativos para a internet, desenvolvendo soluções de comércio eletrônico, sistemas gerenciais e serviços de outsorcing. Em seus 5 anos de existência, a Empresa-A conquistou bons clientes e mantêm-se estável nos negócios, dobrando o tamanho do quadro de funcionários a cada ano e a equipe de desenvolvimento de software é composta de mais de 15 pessoas, envolvendo programadores e designers de interface. Atualmente a Empresa-A possui o versionamento de código fonte localizado em um servidor centralizado na intranet da empresa, utilizando sistema de controle de versão Subversion (também conhecido por SVN), onde cada estação de trabalho possui o cliente SVN TortoiseSVN Windows instalado e cujos utilizadores já estão habituados ao uso. Além de lidar com problemas na infraestrutura da intranet, o que atualmente faz com que operações de "commit" levem cerca de 10 minutos, os produtos desenvolvidos não utilizam ramificações de desenvolvimento, pois, como levantado em entrevistas, em experiências anteriores a Empresa-A perdeu vários dias de trabalho resolvendo conflitos de versão, para alinhar o código de uma ramificação com o ramo principal. É importante destacar que a Empresa-A não utiliza completamente a tecnologia adotada, como por exemplo, desconhecendo o uso de bibliotecas compartilhadas entre projetos ou a adoção de uma política eficaz de releases. A empresa Brasileira Empresa-B foi fundada no ano de 1991, e vem atuando de forma empreendedora no Agronegócio, tendo seu foco principal no segmento de Cooperativas Agropecuárias, Cerealistas, Laticínios, Agroindústrias e Revendas de Insumos Agrícolas, segmento em que consolidou-se como líder de mercado no fornecimento de ERP – Sistemas Integrados de Gestão Empresarial. Seus idealizadores e principais colaboradores são Executivos de Gestão e Informática, com longa vivência em processos de Cooperativas Agropecuárias. São mais de 100 profissionais, que contam com formação superior, em sua maioria, com cursos de pós-graduação e/ou mestrado, e grande experiência na área de desenvolvimento e manutenção de sistemas de informação. A Empresa-B possui elevada maturidade no controle do versionamento do código fonte de seus produtos, e também um servidor centralizado na intranet da empresa, utilizando sistema de controle de versão centralizado Subversion, e cada estação de trabalho possui o cliente SVN Tortoise Windows instalado e customizado com "hooks" que a própria empresa desenvolveu para facilitar rotinas repetitivas. O processo de gerenciamento do código fonte é estável e a empresa não enfrenta problemas com a tecnologia. Mas não foi sempre assim. Segundo o coordenador das equipes de desenvolvimento, a empresa gastou muitas horas resolvendo conflitos, solucionando problemas e alinhando a for-

ma de trabalho de todos. Um do problemas de maior destaque era a “quebra do build” onde um desenvolvedor enviava o código de um módulo com erro para o servidor central e após este envio a compilação de todo o produto parava. Para este tipo de problema a empresa desenvolveu um hook que testa o código antes do envio para o servidor centralizado e também adotou uma regra social chamada “caixinha”, que consistia na cobrança informal de uma multa do desenvolvedor que cometesse a “quebra do build”, e o dinheiro acrescentado à “caixinha” era utilizado em confraternizações da equipe. A Empresa-B utilizou ramificações para separar o código pronto para liberação para a produção mas também evita utilizar ramificações para desenvolvimento, tentando evitar o gasto de tempo com resoluções de conflitos de versões. Tanto a Empresa-A quanto a Empresa-B possuem uma deficiência em comum, com relação ao versionamento do código fonte, que é o fato de que o que acontece no espaço de tempo em que o programador recebe o código fonte do servidor centralizado e o momento em que envia o código modificado não é registrado e versionado, caraterística própria de um Sistema de Controle de Versões Centralizado. Quando um programador precisa executar uma tarefa longa, ele deve optar por não enviar o código até que esteja pronto, não possuindo versionamento de seus passos durante a alteração, ou então requisitar ao administrador do servidor centralizado que este crie uma ramificação onde ele poderá versionar seu código e no momento em que concluir sua tarefa, unir seu novo ramo com o ramo principal, provavelmente enfrentando assim, trabalho extra solucionando conflitos de versões, alternativa esta que é sempre evitada, uma vez que todos passaram por momentos como este no passado, não sendo considerada esta opção viável. A empresa Brasileira Empresa-C não possui versionamento de código fonte e tenta utilizar soluções de rotinas próprias, mantendo um histórico ineficiente do desenvolvimento de seus produtos. A Empresa-A e a Empresa-B consideram de grande valor a utilização de um sistema de controle de versões, pensamento o qual a Empresa-C não compartilha, em razão da cultura organizacional presente, isolada das comunidades de desenvolvimento de software. Nesta amostra, podemos perceber que a maturidade do versionamento do código fonte é definida pela cultura e conhecimento das empresas. A empresa Brasileira Empresa-D desenvolve aplicativos para a internet, no modelo de negócio Offshore Outsourcing, com cliente único localizado na América do Norte, e está em atividade a apenas 3 anos. A Empresa-D nasceu utilizando o Sistema de Controle de Versões Distribuído GIT, influenciada pela comunidade de desenvolvimento de software que utiliza a linguagem de programação Ruby e o framework Ruby on Rails, de tecnologia emergente.

A empresa Estadunidense Empresa-E desenvolve aplicativos para celulares e possui em seu quadro de desenvolvedores, profissionais experientes que passaram por diversas tecnologias de controle de versão de código fonte, e atualmente utiliza também o Sistema de Controle de Versões Distribuído GIT. O projeto Symfony é um framework de código aberto para desenvolvimento de aplicações para internet e seu desenvolvimento que é feito pela comunidade voluntária, teve sua nova versão, de número 2.0, versionado no GitHub, que é um Serviço de Web Hosting Compartilhado para projetos que usam o controle de versionamento Git. A Empresa-D e a Empresa-E já utilizaram os serviços do GitHub em seus projetos. A Empresa-D, a Empresa-E e a comunidade de desenvolvimento do projeto Symfony consideram a adoção do controle de versões de código fonte distribuído um grande salto tecnológico. Os membros das equipes de desenvolvimento das empresas Empresa-D e Empresa-E e os membros da comunidade de desenvolvimento do projeto Symfony, praticamente em sua totalidade, mantém em suas contas GitHub, pequenos projetos de código aberto e acompanham o desenvolvimento de projetos semelhantes, com a leitura de suas atualizações na página do GitHub.

6 PROPOSTA DE SOLUÇÃO DA SITUAÇÃO PROBLEMA

Dois pontos de problemas são destaques na realidade observada nas empresas que utilizam sistemas de versionamento centralizado: • Não existe versionamento do código em desenvolvimento no período entre envios ao servidor central; • Evita-se ramificações em função do custo (tempo).

6.1

PROPOSTA DE MELHORIA PARA A REALIDADE ESTUDADA

A primeira grande diferença no controle de versões de código fonte distribuído é o fato de que cada projeto é um repositório completo, com histórico total e independe de acesso à rede ou um servidor central e “Commits” podem ser feitos offline a qualquer momento . Os desenvolvedores recebem o código, alteram-no, fazem “commit” e repetem este procedimento até que este esteja pronto para o envio a um servidor chave. Os “Commits” podem ser transferidos de um repositório local para outro repositório local, ou seja, um desenvolvedor pode fazer uma parte da tarefa e sem que esta esteja pronta, transferir para outro desenvolvedor que a terminará, e tudo isso sem passar pelo Servidor Central. Somente após concluída, a tarefa é enviada para um servidor chave, que não quer dizer necessariamente central, uma vez que cada repositório é interligado a outro através de roteamento próprio, formando uma rede em forma de teia possibilitando a comunicação repositório a repositório, o que permite várias estratégias de controle. Para exemplificar, analisemos a seguinte estratégia: Desenvolvedores fazem “commits” em seus repositórios locais e trocam informações e enviam seus “commits” para um servidor apelidado de DEV. A engenharia de testes, em seu repositório local, recebe os commits contidos no repositório DEV. Executa testes e remove os commits rejeitados. Envia os commits aprovados para o Repositório PRD que fornece código para a produção. Podemos notar uma engenharia bem diferente da adotada em sistemas de controle de versão centralizado. Nos sistemas de controle de versão distribuídos, como por exemplo o GIT, cada commit pode ser apagado ou então ter suas ações revertidas, o que é muito útil ao

controle de qualidade e rejeição de tarefas. O fato de poder trabalhar com diversos repositórios permite que desenvolvedores possam colocar código no repositório DEV mas não em PRD, onde apenas o controle de qualidade tem acesso de escrita. Os locais rodam o código em produção possuem acesso de leitura a PRD, formando uma infraestrutura propícia à integração contínua. Nesta estratégia, elimina-se o medo da “quebra do build”, uma vez que basta a reversão do commit problemático ainda no controle de qualidade. Os desenvolvedores possuem o histórico de suas alterações locais. O histórico pode ser editado antes do envio para DEV, para que fica melhor organizado. Vários “commits” podem ser unificados, ficando transparente o período de desenvolvimento local. Ainda que removido um commit, o desenvolvedor pode resgatá-lo de um espaço semelhante `a uma lixeira, por um período de 14 dias, no caso só DVCS Git. Este modelo de trabalho – não necessariamente esta estratégia - apresenta-se como solução satisfatória para o problema “Não existe versionamento do código em desenvolvimento no período entre envios ao servidor central”. Além de possuir um algoritmo mais rápido, resultando em tempos de envio e recebimento muito mais curtos comparado a VCSs, a funcionalidade mais atrativa de um DVCS é seu modelo de branches ("bifurcações", ou "galhos") que permite a existência de múltiplos branches locais que podem ser inteiramente independentes de cada um e sua criação, merges ("junções", ou "fusões") e deleção dessas linhas de desenvolvimento ficam sob o controle do desenvolvedor. Nos repositórios chaves estas bifurcações também são possíveis. Os desenvolvedores podem partir da linha de desenvolvimento principal e criar uma ramificação para desenvolver uma nova funcionalidade e assim que esta funcionalidade for concluída, retornar à linha principal, unificar os códigos e então enviar ao repositório chave ou enviar para o repositório de um colega de time de desenvolvimento. Os desenvolvedores podem criar uma ramificação para testar uma idéia, fazer commit algumas vezes, voltar para a partir de onde fizeram a ramificação, aplicar um patch (conjunto de modificações), voltar para onde estão experimentando, então unificar os códigos facilmente. Em algumas estratégias, é uma prática comum ter uma ramificação que sempre contém somente o que vai para produção, e outra ramificação para testar ideias e várias outras menores para atividades do dia a dia e criar novas ramificações para cada nova funcionalidade que estiver trabalhando é uma boa prática. Vamos imaginar o seguinte cenário: O desenvolvedor está desenvolvendo uma nova funcionalidade – que iremos chamar de funcionalidade X - que levará dois meses para

ficar pronta mas no meio deste período é requisitado outra funcionalidade – chamada funcionalidade Y - com prioridade maior e o desenvolvedor deve parar o desenvolvimento da funcionalidade X e alternar para a tarefa de desenvolvimento da funcionalidade Y. Mas seu código não pode ir para produção pois a funcionalidade X não está pronta e isso comprometeria todo o sistema. Em um DVCS, o desenvolvedor criou uma ramificação para a funcionalidade X a partir da linha de desenvolvimento principal e para lidar com este cenário, basta retornar para a linha principal, e criar uma nova ramificação para a funcionalidade Y, desenvolvê-la e então unir as alterações com a linha principal e então enviar para a produção. Após concluir esta tarefa, o desenvolvedor poderá retornar ao ramo da funcionalidade X e concluir seu trabalho, unindo suas modificações ao ramos principal que já contém a funcionalidade Y. Por isso, justifica-se o fato de que a funcionalidade mais enfatizada por Linus Torvalds, criador do DVCS Git e também do Sistema Operacional Linux, em sua apresentação do no Google Open Source Programs Office en Eng Edu em Maio de 2007 foi “branches baratos”, pois tornando simples o processo de criação de ramificações e rápido e simples o processo de retorno à linha de desenvolvimento principal, um DVCS também é uma solução ao problema “Evita-se ramificações em função do custo (tempo)”. Com a execução de “commits” locais, pelo fato do desenvolvedor possuir em seu repositório de desenvolvimento todo o histórico do projeto, os recursos computacionais de rede são economizados, uma vez que o desenvolvedor não precisa utilizar a rede para pesquisar versões diferentes de um arquivo, exibir diferenciações ou pesquisar no histórico.

6.2

RESULTADOS ESPERADOS

A adoção e implantação correta de um DVCS deve resultar em um maior controle do histórico de desenvolvimento local e agilidade de deslocamento do desenvolvedor entre as tarefas em andamento e otimização dos recursos computacionais.

6.3

VIABILIDADE DA PROPOSTA

A adoção de um DVCS é barata e simples. Os DVCSs mais utilizados são softwares livres e de vasta documentação. É ponto facilitador o fato de que os principais DVCSs integrarem-se com os principais softwares de gestão de projetos de software e gestão de configuração, como por exemplo o Trac e o Redmine. Além da linha de comando, os computadores que utilizam Sistema Operacional Windows podem utilizar o software cliente TortoiseGit Windows que é muito semelhante ao cliente SVN TortoiseSVN Windows . Existem diversos clientes GIT para os sistemas operacionais mais utilizados. A preparação de um servidor Git na intranet também é simples, após o aprendizado sobre a estrutura de autenticação por chaves públicas. De modo mais simples, a fábrica de software pode contratar por um custo pequeno o serviço de hospedagem de repositórios Git da empresa GitHub.com, que oferece também contas gratuitas para os usuários e empresas que queiram manter seu código público. Para ter repositórios com acesso privativo é necessário possuir uma conta paga, cujo valor geralmente compensa em vista dos recursos disponíveis e custo zero de investimento em instalação e compra de máquinas. Para desenvolvimento de softwares livres, basta uma conta gratuita no GitHub.com para manter o repositório principal. A migração de um repositório VCS Subversion é facilitada por bibliotecas que realizam a importação de todo o repositório e seu histórico. Antes de decidir pela adoção de um DVCS, a empresa deve investir no aprendizado da equipe para que se evite cenários onde o desenvolvedor não consegue utilizar as ferramentas e abortam a adoção por considerar que um DVCS não é tão bom quanto um VCS, lógica errônea.

7 CONSIDERAÇÕES FINAIS

Adotar um DVCSs deve ser visto como um desafio de quebra de paradigmas e não somente como uma mera troca de tecnologia, uma vez que um sistema distribuído modifi-

ca a forma de trabalho para um formato em célula, incentivando a interação desenvolvedor a desenvolvedor e serviços como GitHub.com atuam como motivador ao amadurecimento de melhores práticas para o uso da tecnologia. Nota-se um relacionamento entre a cultura e conhecimento das empresas e a adoção de novas engenharias. Esta cultura é transformada pela comunidade onde os desenvolvedores participam e em estudos individuais feitos pelos mesmos. Considerando que nossas fábricas de software precisam otimizar seus processos e acompanhar a evolução do conhecimento, reforço neste documento o convite para que os desenvolvedores experientes continuem com o aprendizado incluindo as novas formas de versionamento em seus currículos e para que as empresas que ainda não adotaram a gerência de configuração no processo de desenvolvimento de software o façam, adotando melhores práticas em seus processos. Um DVCS pode ser utilizado independente de outro computador ou servidor central e qualquer projeto, por menor que seja pode ser versionado com poucos e simples procedimentos. Este projeto que resultou neste presente documento foi versionado e mantém seu histórico em seu repositório local. A adoção de um DVCS deve incentivar o uso do controle de versões em outras atividades além dos grandes projetos ou dos projetos de software, podendo atender às diversas necessidades de documentação acadêmica e de desenvolvimento científico.

8

REFERÊNCIAS

Chacon, Scott. Why Git is Better than X [S.l.]: [s.n.], 2010 Disponível em: <http://whygitisbetterthanx.com>. Acesso em: 5 Mar.2011. RAUEN, Fábio José. Roteiros de investigação científica. Tubarão: Unisul, 2002. WIKIPEDIA, a enciclopédia livre. GIT. [S.l.]: [s.n.], 2006. Disponível em: <http://pt.wikipedia.org/wiki/Git>. Acesso em: 3 Mar.2011. WIKIPEDIA, a enciclopédia livre. GitHub. [S.l.]: [s.n.], 2006. Disponível em: <http://pt.wikipedia.org/wiki/GitHub>. Acesso em: 3 Mar.2011. WIKIPEDIA, a enciclopédia livre. Linus Torvalds. [S.l.]: [s.n.], 2006. Disponível em: <http://pt.wikipedia.org/wiki/Linus_Torvalds>. Acesso em: 5 Mar.2011. WIKIPEDIA, a enciclopédia livre. Offshore Outsourcing. [S.l.]: [s.n.], 2006. Disponível em: <http://en.wikipedia.org/wiki/Offshore_outsourcing>. Acesso em: 2 Mar.2011. WIKIPEDIA, a enciclopédia livre. Sistema de controle de versão. [S.l.]: [s.n.], 2006. Disponível em: <http://pt.wikipedia.org/wiki/Controle_de_versão>. Acesso em: 14 Fev.2011. WIKIPEDIA, a enciclopédia livre. Subversion. [S.l.]: [s.n.], 2006. Disponível em: <http://pt.wikipedia.org/wiki/Subversion>. Acesso em: 1 Mar.2011. WIKIPEDIA, a enciclopédia livre. Symfony. [S.l.]: [s.n.], 2006. Disponível em: <http://pt.wikipedia.org/wiki/Symfony>. Acesso em: 3 Mar.2011. YOUTUBE, Tech Talk: Linus Torvalds on git . [S.l.]: [s.n.], 2007. Disponível em: <http://www.youtube.com/watch?v=4XpnKHJAok8>. Acesso em: 5 Mar.2011.