Lançada no dia 27 de junho, a versão 3.1 do Python. Traz as seguintes melhorias:
Informações adicionais podem ser obtidas nos links:
Estão abertas as inscrições para o novo curso de Gerência de Configuração de Software com Trac e Mercurial. A grande novidade é o uso do Mercurial para o controle de versão distribuído.
Mercurial é uma das mais populares ferramentas da nova geração de controle de versão distribuído. É usada por diversos projetos grandes tais como o OpenJDK (Java), NetBeans, Google Code, Python etc.
Possui um conjunto de comandos parecidos com o Subversion, o que facilita o seu aprendizado. Além disso, traz os diversos benefícios do modelo distribuído de controle de versão, tais como independência, rapidez e produtividade.
O curso tem duração de 16 horas e, apesar de apresentar conceitos teóricos, é voltado para a parte prática de Gerência de Configuração, com diversos exemplos e exercícios de fixação do uso conjunto do Trac e do Mercurial para atender às necessidades do dia a dia do desenvolvimento de software e destaque aos novos fluxos de trabalho do modelo distribuído de controle de versão.
O curso também cobre a instalação e configuração do servidor do Trac e de um repositório “oficial” do Mercurial, tratando inclusive de alguns procedimentos de autorização, backup e restauração.
O programa completo está disponível na página do curso.
A próxima turma está marcada para os dias 17 e 18 de agosto em São Paulo.
Faça já sua inscrição e aproveite a promoção de lançamento até o dia 17 de julho (15% de desconto)!
Existem dois tipos de controle de versão: centralizado e o distribuído. O modelo distribuído é mais recente e possui algumas vantagens interessantes sobre o centralizado, embora seja um pouco mais complexo. Para as equipes que decidiram migrar para o distribuído ou mesmo permanecer com o centralizado, ainda resta a questão de qual a melhor ferramenta escolher.
Para aqueles que vão ficar no controle de versão centralizado, a decisão é bem simples: Subversion. Já é um padrão estabelecido, desbancando outros tais como CVS, Visual Source Safe, ClearCase etc. Não há realmente muito a acrescentar neste ponto.
O verdadeiro desafio está na escolha da ferramenta de controle de versão distribuído.
Existem muitas ferramentas de controle de versão distribuído. Para diminuir esse número inicial, vamos usar alguns critérios de filtragem inicial:
Depois de aplicados os critérios na lista, acabam restando praticamente o Git e o Mercurial. Talvez o Bazaar também pudesse ser incluído mas outros como Darcs, Monotone e SVK não passam no critério 3.
A seguir, alguns projetos conhecidos que usam o Mercurial ou o Git:
Critérios de desempate podem ser desempenho, funcionalidades, facilidade de uso, portabilidade, interfaces etc. O problema é que as análises comparativas entre o Mercurial e o Git têm mostrado muito mais semelhanças que diferenças entre os dois. Embora um ou outro tenha uma pequena vantagem em algum dos aspectos, não há diferença realmente significativa que justifique uma decisão baseado nisso.
Processos recentes tem usado outros fatores para o desempate tais como menor curva de aprendizado, suporte à plataforma Windows e preferência dos desenvolvedores para definir a escolha:
Considerando funcionalidades e desempenho equivalentes, o que vai ser importante na escolha são as afinidades do Git ou Mercurial com as características do projeto/equipe/empresa. O desempate acabará sendo feito por critérios mais subjetivos tais como proximidade com outros projetos relacionados e preferência dos desenvolvedores.
Projetos maiores que já usam o Mercurial ou o Git acabam atraindo projetos relacionados para o seu campo de influência.
A interferência direta se dá quando é necessário acompanhar ou mesmo participar de certos projetos externos associados com o projeto da equipe. A escolha da mesma ferramenta para todos torna o controle de versão muito mais fácil pois define um padrão homogêneo.
A tabela a seguir apresenta alguns projetos e qual a ferramenta que usam.
| Projeto | Git | Mercurial |
|---|---|---|
| Google Android | X | |
| Google Code | X | |
| Pylons | X | |
| Python (linguagem) | X | |
| Ruby on Rails | X | |
| Sun (OpenJDK, NetBeans, OpenSolaris) | X |
Esse é o critério mais passional de todos. O que leva um desenvolvedor a preferir uma ferramenta a outra varia desde a identificação com a filosofia do projeto até a preferência pelo logotipo do projeto. De qualquer modo, uma tendência clara da equipe por uma ferramenta específica deve ser pesado na decisão final.
| Projeto X | Projeto Y | Projeto Z | |
|---|---|---|---|
| Escolha Final | Mercurial | Git | Mercurial |
| Plataforma | Windows | Windows/Linux | Linux |
| IDE/Interface | Eclipse | NetBeans | linha de comando |
| Linguagem Principal | Java | Ruby | Python |
| Projetos relacionados usam | Subversion/Mercurial | Git | Subversion/Mercurial |
| Preferência dos Desenvolvedores | - | Git | Mercurial |
Git e Mercurial são ambas ótimas opções de controle de versão distribuído. A análise de um ou outro baseado em número de funcionalidades, forma de implementação interna, desempenho etc. acaba caindo em um tipo de discussão que abunda pelas listas de discussão na internet a fora e que gera muito calor e pouca luz!
Em termos práticos, ambas as ferramentas são muito parecidas e é mais fácil (e prático) escolher entre uma e outra com base na afinidade com o projeto/equipe.
É bom lembrar que controle de versão é muito mais que instalar a ferramenta e sair usando. É necessária a capacitação dos desenvolvedores, a definição de um processo de GCS em sintonia com as particularidades da ferramenta e também integração com uma ferramenta de controle de mudança (por exemplo, o Trac). Já pensando nisso, a Pronus Engenharia de Software lançará em breve o curso de Gerência de Configuração de Software com Trac e Mercurial.
Continuando a série de artigos sobre controle de versão distribuído (Distributed Version Control Systems – DVCS) que começou com a atualização dos conceitos básicos sobre controle de versão e depois para o artigo sobre vantagens e desvantagens do controle de versão distribuído, esse artigo agora analisa a viabilidade ou não da mudança do controle de versão centralizado para o distribuído.
Antes de mais nada, é importante relembrar que controle de versão de software é uma técnica comprovada de engenharia de software. Independente da escolha entre o modelo centralizado ou distribuído, é fundamental que algum controle de versão seja usado.
Para ajudar na escolha, siga o fluxograma a seguir:
A mudança do controle de versão centralizado pelo distribuído é mais que uma questão apenas de troca de ferramenta. Implica ajustes no processo e também capacitação da equipe de desenvolvimento.
Controle de versão distribuído traz vantagens sim, mas não torna o controle de versão centralizado obsoleto. A decisão de passar de um tipo para outro deve ser analisada com cuidado. De preferência com experimentações para gerar algum tipo de opinião própria e depois com muito planejamento para que não haja surpresas.
A tabela a seguir apresenta sugestões de mudança de acordo com o perfil do uso de controle de versão:
| Uso atual do controle de versão | Vale a pena mudar para o Distribuído? | Comentários |
|---|---|---|
| Não usa | Subutiliza | Sim | Invista na mais nova geração de controle de versão de uma vez! A definição e um processo e capacitação da equipe ajudarão na melhoria da qualidade do software. |
| Insatisfatório pois se encaixa no perfil DVCS | Talvez | Depende de alguns fatores. Entre eles de quanto os problemas atrapalham o andamento do projeto. |
| Satisfatória | Não | Projetos atuais não devem migrar. Mas experimentações são bem-vindas em projetos-piloto. |
Quem mexe com desenvolvimento Web com certeza já ouviu falar de JQuery. Da própria descrição do site:
jQuery é uma biblioteca Javascript rápida e concisa que simplifica manipulação do documento HTML, lidar com eventos, animação e interações Ajax para desenvolvimento web rápido…
Para quem está começando, indico dois tutoriais interessantes:
Foi lançada a versão 1.6.2 do Subversion. Entre as melhorias da versão 1.6 estão:
Para o servidor, basta instalar a nova versão. Para os desenvolvedores que usam Windows, a melhor alternativa de atualização é pegar a versão mais nova do TortoiseSVN
Versões anteriores de clientes e servidores operaram sem problemas com a versão 1.6 de clientes e servidores. Entretanto, algumas funcionalidades da versão 1.6 não estarão disponíveis a não ser que tanto o cliente e o servidor tenham a versão mais nova.
Não há necessidade de fazer o ciclo dump/reload dos repositórios. A versão 1.6 do Subversion lê normalmente os repositórios criados por versões anteriores.
Controle de versão distribuído (Distributed Version Control Systems – DVCS) é a mais nova geração de sistemas de controle de versão de software. Apesar de o conceito existir já há algum tempo, recentemente as ferramentas se tornaram maduras o suficiente para chamar a atenção de diversos projetos open source, que migraram ou expandiram seu suporte do Subversion (centralizado) para o Mercurial, Git e Bazaar (distribuídos) por exemplo.
Mas o que tem de errado com o controle de versão centralizado? Nada. Ele usa uma estrutura que atende muito bem a grande parte das equipes de desenvolvimento de software. Baseia-se na arquitetura cliente-servidor, com um repositório central (servidor) e cópias de trabalho para os desenvolvedores (clientes).
Para equipes de desenvolvimento com acesso ao repositório pela rede local, essa arquitetura funciona bem. A velocidade da rede não é problemática, o tempo de resposta do processamento é aceitável e todos os desenvolvedores da equipe têm permissão de leitura e escrita no repositório.
Não foi para resolver exatamente esse tipo de necessidade que o controle de versão distribuído foi criado. Imagine uma situação diferente:
A arquitetura cliente-servidor não funciona tão bem para essas situações. Soluções alternativas como aumentar a capacidade de processamento do servidor ou replicar os repositórios nem sempre são viáveis ou fáceis de serem implementadas.
Para essas situações, a arquitetura peer-to-peer, na qual o controle de versão distribuído se baseia, é muito mais adequada.
As vantagens estão relacionadas à distribuição do processamento, redundância/replicação de repositórios e as novas possibilidades de colaboração entre desenvolvedores.
Parte das decisões gerenciais envolve manter livre o caminho da equipe para que possam trabalhar da melhor maneira possível. Outras decisões importantes são sobre redução de custos. Nestes dois casos específicos, o modelo distribuído oferece as seguintes vantagens:
Nem tudo são flores com o modelo distribuído de controle de versão.
No centralizado, os desenvolvedores trabalham no mesmo ramo, seja esse ramo o principal ou um ramo de manutenção.
Essa forma de trabalho é mais simples de se entender. Mesmo que limitadamente, uma pessoa com pouco conhecimento de controle de versão consegue trabalhar com o resto da equipe.
O modelo distribuído é mais complicado. A arquitetura peer-to-peer, ramos privativos e as mesclagens aparentemente desordenadas podem tornar o grafo da evolução do projeto confuso à primeira vista.
Ao contrário do centralizado, não adianta só commit e update para funcionar “no tranco”. Todos os desenvolvedores da equipe precisam ter um conhecimento maior do modelo, da ferramenta e, de preferência, também de um processo de desenvolvimento que padronize fluxos de trabalho a serem seguidos. Só assim, o grafo acima deixa de ser apenas um emaranhado e passa a representar muito claramente o fluxo do trabalho.
Diferentemente dos arquivos de texto, arquivos binários possuem um formato interno que não é baseado em linhas de texto e, por isso, não podem ser mesclados automaticamente pelo controle de versão ou manualmente pelo desenvolvedor.
Sendo assim, a edição concorrente de arquivos binários é problemática. Duas pessoas editando ao mesmo tempo uma figura, por exemplo, não conseguirão mesclar as modificações depois e o trabalho de uma delas precisará ser refeito.
Com arquivos binários, a melhor solução é usar o travamento, isto é, sinalizar que o arquivo está travado para edição e que ninguém mais deve editá-lo enquanto isso.
O modelo puramente distribuído não é adequado para lidar com travamento justamente por não possuir um servidor central que possa controlar as travas de todos.
As ferramentas de controle de mudança (e.g. Trac, Redmine, Mantis, Bugzilla) ainda não acompanharam as de controle de versão na arquitetura peer-to-peer. Isto significa que mesmo usando um DVCS, ainda haverá uma ferramenta centralizada para controle de mudança.
O ideal seria que o controle de versão e o controle de mudança fossem integrados e distribuídos, tal como é no Fossil. Essa ferramenta parece ser interessante, mas ainda é muito incipiente.
| Ponto de Vista | Vantagens | Desvantagens |
|---|---|---|
| Desenvolvedor |
|
|
| Coordenação/Gerência |
|
|
Controle de versão distribuído oferece muitas vantagens interessantes. Mesmo projetos que não se encaixam diretamente no perfil podem se beneficiar. Entretanto, por ser um pouco mais complexo, o modelo distribuído requer mais preparo da equipe e também do processo, o que não chega a ser realmente um impedimento uma vez que um processo formalizado e equipes capacitadas são fundamentais para produção de software de qualidade.
Em um próximo artigo, vou analisar alguns pontos que ajudarão a decidir a viabilidade ou não de se mudar do centralizado para o controle de versão distribuído.
