1. Leonardo Santagada
  2. trabalho_dvcs

Source

trabalho_dvcs / inicial.txt

começa com o texto da canonical

falar o que é o desenvolvimento de sw (comunicação)
falando sobre colaboracao (configuration managemanent - wiki)

----- ----- ----- ----- -----

Desafios do desenvolvimento de software

Conforme (texto do Ian) comenta, os desafios na construção de um software são sempre os mesmos, independentemente de ser ele código livre ou comercial. 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 dele, 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?

----- ----- ----- ----- -----

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.

----- ----- ----- ----- -----

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. 

1. Cópia de Trabalho (citar quais funcionam assim)

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.

2. Política TRAVA-MODIFICA-DESTRAVA (centralizado? Exemplos...)

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.

3. Política COPIA-MODIFICA-RESOLVE (distribuído - Git, Mercurial, Bazaar)

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 "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 foco deste artigo será o DCVS mas, antes, vamos mostrar como funciona um CVS tradicional para, com isso, podermos mostrar as vantagens e desvantagens de um sistema de versionamento distribuído.