Source

trabalho_dvcs / inicial.tex

Full commit
\section{Introdução}
\subsection{Desafios do desenvolvimento de software}

Os desafios na construção de um software são sempre os mesmos, independentemente de ser ele código livre ou comercial\cite{Clatworthy:2008p761}. Mencionando Fred Brooks, não existe uma bala de prata para acabar com o monstro do desenvolvimento de software. Quanto mais interessante o software, mais inerentemente complexo ele é e mais os usuários vão querer que ele fique pronto o quanto antes. Entretanto, eles não vão tolerar um trabalho de baixa qualidade.

Um programa também normalmente não é considerado terminado enquanto ainda tem usuários dando idéias do que poderia ser feito, mudanças de requisitos, novos ambientes ou ainda a presença de bugs. Com isso, o desenvolvimento de um programa não é mais algo estático, mas um gerenciamento da evolução do design, da comunicação dentre a equipe de desenvolvimento e de como dar suporte para que eles entendam o que já havia sido feito por outros.

A engenharia de software é, ainda na opinião de \cite{Clatworthy:2008p761}, um desafio de comunicação. A cada nova versão, o caminho que leva das idéias para algo concreto envolve cada vez mais pessoas. Em grandes organizações, por exemplo, esse pessoal inclui usuários, patrocinadores, analistas de negócios, arquitetos, gerentes de projetos, engenheiros de software, documentadores, engenheiros de qualidade, engenheiros de suporte, etc. A história da ciência da computação tem feito a sua parte tornar essa cadeia comunicativa mais eficiente: linguagens de programação de alto níveo, OO, casos de uso, UML, padrões de design e métodos ágeis, entre outros. Ultimamente, o desafio principal do desenvolvimento de programas é: Como fazer para colaborarmos mais eficientemente, instantaneamente e continuamente?

\subsection{O papel do Gerenciamento de Configuração}

O gerenciamento de configuração é a base das melhores práticas das metodologias de engenharia de software independentemente do tipo da metodologia.  Modelo em cascata, espiral, interativo, ágil; para todos o gerenciamento de configuração é fundamental porque as ferramentas de controle de versão provaram ser hoje em dia o caminho mais eficiente, em termos de custo/benefício, para a comunicação técnica das mudanças ocorridas durante o tempo em âmbito mundial. Como consequência, as melhorias da tecnologia de controle de versão têm um impacto direto na efetividade da colaboração do material produzido. Não surpreendentemente, duas grandes forças por trás dessa tecnologia são Mark Shuttleworth e Linus Torvalds. Na opinião de Mark, ``Merging é a chave para a colaboração no desenvolvimento de código''. Já Linus acredita fortemente que ferramentas de controle de versão ajudam muito o desenvolvimento.

\subsection{Como Funciona o Gerenciamento de Configuracão}

Conforme descrição da Wikipédia, a gerencia de configuração é a área da Engenharia de Software responsável pelo suporte ao desenvolvimento através do controle de versão, controle de mudanças e auditoria de configurações. Roger Pressman, em seu livro (Software Engineering: A Practitioner's Approach), afirma que a gerência de configuração de software (GCS) é “o conjunto de atividades projetadas para controlar as mudanças pela identificação dos produtos do trabalho que serão alterados, estabelecendo um relacionamento entre eles, definindo o mecanismo para o gerenciamento de diferentes versões destes produtos, controlando as mudanças impostas, e auditando e relatando as mudanças realizadas.” Com isso, a gerência de configuração procura responder o que mudou e quando, por que mudou, quem fez a mudança e se podemos reproduzir esta mudança. O papel de um um bom sistema de controle de versões é conseguir responder a essas perguntas.

Um dos maiores desafios da área é resolver o problema do compartilhamento de arquivos. Como dito anteriormente, cada vez mais tem mais pessoas envolvidas no desenvolvimento de um projeto e, se não houver alguma forma de se sincronizar o que cada um está fazendo, o resultado final pode ser comprometido. Por isso, a (wikipedia) apresenta três maneiras de como se resolver esse problema. 

\subsubsection{Cópia de Trabalho}

Os desenvolvedores não trabalham diretamente nos arquivos do repositório. Cada desenvolvedor possui uma cópia de trabalho que espelha os arquivos do repositório para trabalhar com liberdade enquanto termina suas tarefas, isolado dos outros desenvolvedores.

\subsubsection{Política \emph{trava-modifica-destrava}}

Nessa política, o sistema de controle de versão permite que apenas um desenvolvedor por vez altere um determinado arquivo do projeto. Ela é restritiva e frequentemente atrapalha o trabalho dos usuários. O travamento pode causar alguns problemas administrativos e forçar a uma serialização desnecessária. Alguns dos sistemas que funcionam assim são o ClearCase da Rationa e o Visual Source Safe da Microsoft. Esse controle de versão é pessimista pois espera que as mudanças criadas pelos desenvolvedores causam muitos conflitos. Essa nomeclatura de otimista e pessimista foi adaptada dos sistemas de transação de bancos de dados.

\subsubsection{Política \emph{copia-modifica-resolve}}

Nessa política, não existe travamento de arquivos. Cada desenvolvedor trabalha livremente em qualquer arquivo da sua cópia de trabalho. Ao final, as alterações de cada desenvolvedor são mescladas no repositório formando a versão final. A solução \emph{copia-modifica-resolve} parece um pouco estranha e bagunçada a princípio, mas funciona bem na prática. Conflitos são raros e são causados basicamente pela falta de comunicação entre desenvolvedores. Na grande maioria dos casos, as alterações não se sobrepõe e são mescladas automaticamente pelo sistema de controle de versão. O CVS (Concurrent Version System) e Subversion funcionam dessa forma por padrão. Esse método de funcionamento também é conhecido como otimista pois é esperado que raramente aconteçam conflitos.

Apresentaremos agora como tradicionalmente funciona o controle de versão para podermos comparar com o modelo distribuido e ver as vantagens e desvantagens de cada um deles.
% O foco deste artigo será o DVCS mas, antes, vamos mostrar como funciona um VCS tradicional para, com isso, podermos mostrar as vantagens e desvantagens de um sistema de versionamento distribuído.