Benefícios do Controle de Versões Distribuído para Projetos de Software

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


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


Este trabalho de pesquisa na modalidade de Estudo de
Caso foi julgado adequado à obtenção do grau de Tec-
nólogo em Gestão da Tecnologia da Informação e apro-
vada em sua forma final pelo Curso Superior de Tecno-
logia em Gestão da Tecnologia da Informação da Uni-
versidade 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 conhe-
cimento livre advindo de grandes mentes doadoras.
Agradeço a Deus por ter-nos dado tal comunidade em modelo Bazar e não uma com-
plexa 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 centraliza-
dos. O estudo de caso realizado visualizou a aplicabilidade da adoção de um sistema de con-
trole 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 conhecimen-
to 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 incenti-
vam 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 desenvolvimen-
to 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 con-
flito 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 sis-
temas 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 Softwa-
re (SCM).
O modelo de sistema de controle de versões tradicional e mais utilizado é o cen-
tralizado.
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 Ker-
nel 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 dis-
tribuído (DVCS) para projetos de software

2.1 PROBLEMA

O problema a ser resolvido é a incompreensão do modelo distribuído, impedimen-
to 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 dis-

tribuí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 Sys-
tem) 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 pou-
cos 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 clas-
sificado 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 en-
trevista, 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ódi-
go 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 qua-
dro a seguir.

Instrumento de Universo pesquisado Finalidade do Instrumento
coleta de dados
Serão entrevistados 5 líderes de A finalidade destas entrevistas é
Entrevista equipes de desenvolvimento de mapear os problemas relaciona-
software, sendo que 3 destes líde- dos ao uso do sistema de contro-
res atuam em empresas Brasilei- le de versões e benefícios adqui-
ras, utilizando Sistema de controle ridos com a mesma utilização,
de versões centralizado e 2 destes fazendo comparação entre os re-
líderes atuam em empresas Esta- sultados de engenharias diferen-
dunidenses e utilizam Sistema de tes.
controle de versões distribuído
Serão utilizados as documentações O objetivo é entender a engenha-
Documentos para desenvolvedores de projetos ria e possibilidades das tecnolo-
de software livre que utilizam Sis- gias de versionamento.
tema de controle de versões, ma-
nuais oficiais dos próprios siste-
mas de controle de versões, e li-
vros didáticos sobre o assunto.
Também serão utilizadas páginas
web relatando casos de utilização,
problemas e benefícios em deter-
minada implantação.
Quadro 1- Instrumento de coleta de dados.
Fonte: Unisul Virtual, 2007.

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 desenvol-
vimento de software é composta de mais de 15 pessoas, envolvendo programadores e desig-
ners de interface. Atualmente a Empresa-A possui o versionamento de código fonte localiza-
do em um servidor centralizado na intranet da empresa, utilizando sistema de controle de ver-
sã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 Em-
presa-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 utili-
za completamente a tecnologia adotada, como por exemplo, desconhecendo o uso de bibliote-
cas 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, seg-
mento em que consolidou-se como líder de mercado no fornecimento de ERP – Sistemas Inte-
grados 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 cur-
sos de pós-graduação e/ou mestrado, e grande experiência na área de desenvolvimento e ma-
nutençã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 in-
tranet 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 tecnolo-
gia. 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 de-
senvolveu 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 mul-
ta do desenvolvedor que cometesse a “quebra do build”, e o dinheiro acrescentado à “caixi-
nha” 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 ver-
sionamento de seus passos durante a alteração, ou então requisitar ao administrador do servi-
dor centralizado que este crie uma ramificação onde ele poderá versionar seu código e no mo-
mento 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 desenvolvi-
mento 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 mo-
delo 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 diver-
sas 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 proje-
tos.
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 Em-
presa-E e os membros da comunidade de desenvolvimento do projeto Symfony, praticamen-
te 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 Servi-
dor 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 repo-
sitó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óri-
os 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 à inte-
gração contínua.
Nesta estratégia, elimina-se o medo da “quebra do build”, uma vez que basta a re-
versã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 orga-
nizado. Vários “commits” podem ser unificados, ficando transparente o período de desenvol-
vimento 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 desenvolvimen-
to no período entre envios ao servidor central”.
Além de possuir um algoritmo mais rápido, resultando em tempos de envio e rece-
bimento 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 funciona-
lidade 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 funcio-
nalidade Y - com prioridade maior e o desenvolvedor deve parar o desenvolvimento da fun-
cionalidade 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 funcionalida-
de X a partir da linha de desenvolvimento principal e para lidar com este cenário, basta retor-
nar para a linha principal, e criar uma nova ramificação para a funcionalidade Y, desenvol-
vê-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 Tor-
valds, 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 bara-
tos”, pois tornando simples o processo de criação de ramificações e rápido e simples o pro-
cesso 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 pesqui-
sar 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 prin-
cipais softwares de gestão de projetos de software e gestão de configuração, como por exem-
plo 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 aprendiza-
do sobre a estrutura de autenticação por chaves públicas.
De modo mais simples, a fábrica de software pode contratar por um custo peque-
no 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 aprendiza-
do da equipe para que se evite cenários onde o desenvolvedor não consegue utilizar as ferra-
mentas 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 desenvolve-
dores 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 conheci-
mento, reforço neste documento o convite para que os desenvolvedores experientes continu-
em 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 desenvol-
vimento de software o façam, adotando melhores práticas em seus processos.
Um DVCS pode ser utilizado independente de outro computador ou servidor cen-
tral e qualquer projeto, por menor que seja pode ser versionado com poucos e simples proce-
dimentos. 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, po-
dendo atender às diversas necessidades de documentação acadêmica e de desenvolvimento ci-
entífico.

8 REFERÊNCIAS

Chacon, Scott. Why Git is Better than X [S.l.]: [s.n.], 2010 Disponível em: <http://whygitis-
betterthanx.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.wikipe-
dia.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. Dispo-
ní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.wi-
kipedia.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.

Benefícios do Controle de Versões Distribuído para Projetos de Software

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Benefícios do Controle de Versões Distribuído para Projetos de Software

Similaire à Benefícios do Controle de Versões Distribuído para Projetos de Software (20)

Plus de Gilmar Pupo

Plus de Gilmar Pupo (6)

Benefícios do Controle de Versões Distribuído para Projetos de Software