gerência de configuração de software: benefícios do controle de versões distribuído para...

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

coleta de dados

Universo pesquisado Finalidade do Instrumento

Entrevista

Serão entrevistados 5 líderes de

equipes de desenvolvimento de

software, sendo que 3 destes líde-

res atuam em empresas Brasilei-

ras, utilizando Sistema de controle

de versões centralizado e 2 destes

líderes atuam em empresas Esta-

dunidenses e utilizam Sistema de

controle de versões distribuído

A finalidade destas entrevistas é

mapear os problemas relaciona-

dos ao uso do sistema de contro-

le de versões e benefícios adqui-

ridos com a mesma utilização,

fazendo comparação entre os re-

sultados de engenharias diferen-

tes.

Documentos

Serão utilizados as documentações

para desenvolvedores de projetos

de software livre que utilizam Sis-

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.

O objetivo é entender a engenha-

ria e possibilidades das tecnolo-

gias de versionamento.

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.

gerência de configuração de software: benefícios do controle de versões distribuído para...

Technology