Gerência de Configuração de Software: Benefícios Do Controle de Versões Distribuído para Projetos de Software
Upcoming SlideShare
Loading in...5
×
 

Gerência de Configuração de Software: Benefícios Do Controle de Versões Distribuído para Projetos de Software

on

  • 2,058 views

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 ...

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.

Statistics

Views

Total Views
2,058
Views on SlideShare
2,056
Embed Views
2

Actions

Likes
0
Downloads
32
Comments
0

2 Embeds 2

http://www.slideshare.net 1
http://www.linkedin.com 1

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Gerência de Configuração de Software: Benefícios Do Controle de Versões Distribuído para Projetos de Software Gerência de Configuração de Software: Benefícios Do Controle de Versões Distribuído para Projetos de Software Document Transcript

  • 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 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 View slide
  • 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. View slide
  • RESUMO Este projeto sugere melhorias no modelo de versionamento de arquivos de um projeto desoftware 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 acultura 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 sistemasde 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 recursoscomputacionais 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 pelaGerência de Configuração de Software pode ser simples desde que reconhecido como umnovo paradigma. Palavras-chave: Desenvolvimento de Software; Engenharia de Software, Sistemade controle de versão.
  • Sumário1 INTRODUÇÃO.....................................................................................................................72 TEMA.....................................................................................................................................82.1 PROBLEMA......................................................................................................................................................82.2 JUSTIFICATIVA...............................................................................................................................................83 OBJETIVOS..........................................................................................................................93.1 OBJETIVO GERAL..........................................................................................................................................93.2 OBJETIVOS ESPECÍFICOS.............................................................................................................................94 PROCEDIMENTOS METODOLÓGICOS.....................................................................104.1 CAMPO DE ESTUDO.....................................................................................................................................104.2 INSTRUMENTOS DE COLETA DE DADOS...............................................................................................105 APRESENTAÇÃO E ANÁLISE DA REALIDADE OBSERVADA.............................116 PROPOSTA DE SOLUÇÃO DA SITUAÇÃO PROBLEMA.........................................136.1 Proposta de melhoria para a realidade estudada...............................................................................................136.2 Resultados esperados........................................................................................................................................136.3 Viabilidade da proposta....................................................................................................................................137 CONSIDERAÇÕES FINAIS.............................................................................................14 REFERÊNCIAS....................................................................................................................15
  • 1 INTRODUÇÃO O desenvolvimento de software evolui em ritmo acelerado e muitos problemasfrequentemente enfrentados são solucionados a cada dia. Problemas relacionados ao rastreamento de alterações no desenvolvimento de umsoftware 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 estaevolução que este projeto aborda.
  • 2 TEMA Um sistema de controle de versão, em seu conceito primordial, além de ser umum software para gerenciar diferentes versões de um documento qualquer, é o processo deguardar o histórico de alterações de diferentes arquivos. Um grande número de equipes de desenvolvimento de softwares utilizam esteconceito de versionamento para o código fonte, e em organizações com processos certificadosde 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 decontrole 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 software2.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 decontrole 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 projetosde software?
  • 2.2 JUSTIFICATIVA A escolha desse tema virá contribuir, em certa medida, para melhoria do processode 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 OBJETIVOS3.1 OBJETIVO GERAL Este trabalho tem como objetivo apresentar possibilidades e benefícios de uso deum 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 dedesenvolvimento de projetos de software, esclarecendo diferenças comumente vistas comomeras 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ÓGICOS4.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 permitiro 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 paraaplicação prática e dirigidos à solução de problemas específicos, e foi estruturada por meio deuma 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 empresasque 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 nosnegó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 clienteSVN TortoiseSVN Windows instalado e cujos utilizadores já estão habituados ao uso. Alémde lidar com problemas na infraestrutura da intranet, o que atualmente faz com que operaçõesde "commit" levem cerca de 10 minutos, os produtos desenvolvidos não utilizam ramificaçõesde 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ódigode 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 deforma empreendedora no Agronegócio, tendo seu foco principal no segmento de CooperativasAgropecuá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 Executivosde 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 controledo 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 cadaestaçã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 degerenciamento 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, aempresa 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” ondeum desenvolvedor enviava o código de um módulo com erro para o servidor central e apóseste 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émadotou 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 paraseparar 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 deversõ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çode tempo em que o programador recebe o código fonte do servidor centralizado e o momentoem que envia o código modificado não é registrado e versionado, caraterística própria de umSistema de Controle de Versões Centralizado. Quando um programador precisa executar umatarefa 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, provavelmenteenfrentando 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 sendoconsiderada esta opção viável. A empresa Brasileira Empresa-C não possui versionamento de código fonte etenta 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 umsistema de controle de versões, pensamento o qual a Empresa-C não compartilha, em razãoda cultura organizacional presente, isolada das comunidades de desenvolvimento de software. Nesta amostra, podemos perceber que a maturidade do versionamento do códigofonte é 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, eestá em atividade a apenas 3 anos. A Empresa-D nasceu utilizando o Sistema de Controlede Versões Distribuído GIT, influenciada pela comunidade de desenvolvimento de softwareque utiliza a linguagem de programação Ruby e o framework Ruby on Rails, de tecnologiaemergente.
  • A empresa Estadunidense Empresa-E desenvolve aplicativos para celulares epossui 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 Sistemade Controle de Versões Distribuído GIT. O projeto Symfony é um framework de código aberto para desenvolvimento deaplicações para internet e seu desenvolvimento que é feito pela comunidade voluntária, tevesua nova versão, de número 2.0, versionado no GitHub, que é um Serviço de Web HostingCompartilhado 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 projetoSymfony consideram a adoção do controle de versões de código fonte distribuído um grandesalto 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 eacompanham o desenvolvimento de projetos semelhantes, com a leitura de suas atualizaçõesna 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 é ofato 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 repetemeste 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 estejapronta, 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 querdizer necessariamente central, uma vez que cada repositório é interligado a outro através deroteamento 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” paraum servidor apelidado de DEV. A engenharia de testes, em seu repositório local, recebe oscommits contidos no repositório DEV. Executa testes e remove os commits rejeitados. Enviaos 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 controlede versão centralizado. Nos sistemas de controle de versão distribuídos, como por exemplo oGIT, 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 emPRD, onde apenas o controle de qualidade tem acesso de escrita. Os locais rodam o códigoem 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 comosoluçã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últiplosbranches 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 dodesenvolvedor. Nos repositórios chaves estas bifurcações também são possíveis. Os desenvolvedores podem partir da linha de desenvolvimento principale 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, fazercommit 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ódigosfacilmente. Em algumas estratégias, é uma prática comum ter uma ramificação que semprecontém somente o que vai para produção, e outra ramificação para testar ideias e várias outrasmenores para atividades do dia a dia e criar novas ramificações para cada nova funcionalidadeque estiver trabalhando é uma boa prática. Vamos imaginar o seguinte cenário: O desenvolvedor está desenvolvendo umanova 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 comprometeriatodo 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ósconcluir esta tarefa, o desenvolvedor poderá retornar ao ramo da funcionalidade X e concluirseu trabalho, unindo suas modificações ao ramos principal que já contém a funcionalidadeY. 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 dono 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 aoproblema “Evita-se ramificações em função do custo (tempo)”. Com a execução de “commits” locais, pelo fato do desenvolvedor possuir em seurepositório de desenvolvimento todo o histórico do projeto, os recursos computacionais derede 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 controledo histórico de desenvolvimento local e agilidade de deslocamento do desenvolvedor entre astarefas 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ãosoftwares 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 OperacionalWindows podem utilizar o software cliente TortoiseGit Windows que é muito semelhante aocliente 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émcontas gratuitas para os usuários e empresas que queiram manter seu código público. Para terrepositórios com acesso privativo é necessário possuir uma conta paga, cujo valor geralmentecompensa em vista dos recursos disponíveis e custo zero de investimento em instalação ecompra 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 querealizam 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 enã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 adesenvolvedor e serviços como GitHub.com atuam como motivador ao amadurecimento demelhores 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 paraque 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 seuhistórico em seu repositório local. A adoção de um DVCS deve incentivar o uso do controlede 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ÊNCIASChacon, 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.