Oi,
Estou definindo uma nova política de SCM e me baseando um pouco na experiência passada e em boas práticas que encontrei. Alguém conhece bons documentos de SCM? Pode comentar a prática adotada na sua empresa apra discutirmos?
Basicamente estou adotando regras simples de um branch por release, tags a vontade.
Será que não seria melhor uma tag por release não?
Acho que branchs são coisas pra se utilizar apenas em caso de experimentação ou mudanças muito grandes na estrutura do projeto.
Eu estava pensando inicialmente em tags por relase e branches quando efetivamente for feita alguma manutenção, mas não vi muita utilidade em não gerar logo um branch.
O problema em apenas taggear é que você vai ter que dar manutenção no release antes da próxima versão ser lançada e se você não mantêm branches sua base de código se mistura.
Tipo:
Head—TAG_V1-------------------TAG_V2—>
Se eu preciso alterar algo em V1 para manutenção enquanto está sendo desenvolvido V2 eu não consigo fazer uma nova versão (1.1) sem ter tudo que foi desenvolvido até então para V2, o que não é desejável.
Com vários branches:
Head---------------------------------------------------&
| |
V1---------| V2---------------|(a tentativa de desenho ficou horrível)
Eu tenho acesso ao código de V1 sem interferir no head enquanto V2 é desenvolvido.
O problema de trabalhar com 1 branch para cada versão é quando a coisa for convergir (merge).
Já passamos por este tipo de discussão na nossa empresa e o ideal for definir mais de uma politica, dependendo do tipo de projeto:
[list]Default: usar apenas o HEAD e tags para gerar as versões. Excepcionalmente, abre-se um branch para lançar uma versão de manutenção no caso de não pode usar o proprio HEAD para isto (já foram comiitadas modificações que não foram testadas ou não podem ir na versão anterior). A modificação aplicada no branch deve “rapidamente” ser aplicada na linha de desenvolvimento da próxima versão. Esta política supõem que não há manutenção em versões passadas, apenas na versão em produção (stable).[/list]
[list]Várias versões para manutenção: ai seria o caso de ter um branch para cada versão. Teria que existir politicas de convergencia de código (por tempo ou por feature) para que a versão mais recente também tenha a modificação do branch aplicada. Isto pode ser extremamente complexo dependendo do software de controle de versão utilizado. O CVS tem poucos recursos para uma boa administração disto. Dependendo do tamanho da equipe, vale a pena “burocratizar” o processo, criando mecanismos de controle próprio (criar scipts que verificam permissões de commits e depenencias de versões).[/list]
Eu tinha um artigo publicado na Dr. Dobb’s a muito tempo que explanava sobre a utilização do CVS para SCM. Se eu achar o artigo eu posto aqui.
Espero ter ajudado.
Hm… eu não consigo pensar em como um projeto com mais de um release consiga sobreviver à primeira opção.
A política de merge é simples: completou a tarefa (provavelmente um bugfix) em um branch faz merge em todos os que também são afetados imediatamente. A tarefa só está concluída após os merges.
Fazer merge é chato e trabalhoso mas se você contar que não fazer é mortal, então não tem jeito.
o chato é fazer merge de hora em hora, no mais tá blza
Aqui nós conseguimos sobreviver com esta politica na maioria dos projetos 
Boas praticas para isto dar certo:
[list]Periodos relativamente curtos entre uma versão/release e outra. Trabalhamos com um periodo de 3 meses.[/list]
[list]Os clientes terem uma política de ter sempre a versão mais recente em produção. Sei que isto é extremamente difícil, mas usando a política de se deu pau e não está com a última versão, então tem que migrar para a versão mais recente para ter a correção.[/list]
[quote=pcalcado]
A política de merge é simples: completou a tarefa (provavelmente um bugfix) em um branch faz merge em todos os que também são afetados imediatamente. A tarefa só está concluída após os merges.
Fazer merge é chato e trabalhoso mas se você contar que não fazer é mortal, então não tem jeito.[/quote]
Tentamos isto em um projeto, mas deu muito stress. A maioria dos programadores não realizava a tarefa corretamente e não tinhamos uma boa ferramenta para gerenciarmos isto. Bem, no nosso caso, a experiencia não foi boa.
Isso me lembra um projeto há alguns anos-luz atrás. Tivemos que descompilar os binários apra provar que o sistema em produção não estava na última versão enviada. Passamos então a colocar como uma String no fonte o número da versão, um comando ‘strings’ do Unix resolvia.
De qualquer modo, isto não é viável no meu cenário, geralmente o cliente está com uma versão em produção, ahcam um bug. Enquanto aquela está em produção, temos que homologar uma versão com bugfix, isso tudo enquanto no Head estão desenvolvendo a nova versão.
[quote=oyama]
Tentamos isto em um projeto, mas deu muito stress. A maioria dos programadores não realizava a tarefa corretamente e não tinhamos uma boa ferramenta para gerenciarmos isto. Bem, no nosso caso, a experiencia não foi boa.[/quote]
Na última empresa que trabalhei isso era integrado com o processo. Havia um mergeblamer integrado ao Subversion que mandava emails diários com o que não foi integrado, funcionava muito razoavelmente. Além disso, a política do ‘se não integrou não fechou a task’ motiva porque a pessoa não pode dizer pro gerente que acabou até fazê-lo.
Claro que no calor da batalha contra um bug as coisas acabam sendo ingonardas mas o mergeblamer sempre lembra ao gerente de configurações que tem gente em dívida.
Olá
Para aqueles que como eu acompanham este tópico e boiaram no tal de Merge & Blame que o Phillip falou, aqui um link do no forum do subversion que achei interessante:
http://svn.haxx.se/users/archive-2004-07/0098.shtml
Algumas respostas:
http://svn.haxx.se/users/archive-2004-07/0101.shtml
http://svn.haxx.se/users/archive-2004-07/0105.shtml
Philip, qual SCM que está usando? Ainda usa o Perforce?
[]s
Luca
Nada, passei para Subversion em outro projeto e acabo de mudar para uma empresa que já tem CVS para dois projetos anteriores.
Se dependesse de mim os projetos novos iam pro Subversion mas isso é uma negociação um pouco complexa 
Só um comentário, tags são estáticas, você não pode modificar uma versão tag. Para isso você têm que criar uma branch aparti dessa tag.
Exemplo de repositório (usando subversion):
/tags
/V_1.0
/V_1.1
/V_1.1.1
/M_1.1.1.345
/M_2.0.0.3864
/branches
/V_1.1.1
/trunk
/shelves
/peleteiro
/fulano
/sicrano
/trunk é sempre a versão que está sendo produzida (major release, no exemplo seria a 2.0).
Em branches está, quando necessário, alguma versão que já foi lançada (cópia aparti do /tags) para bugfixes e/ou alguma evolutiva quando necessário. Quando essa versão for finalizada, ela recebera um novo número (no exemplo se houve só correção de bugs 1.1.2, se houve mudança de funcionalidade 1.2) e então é movida para tags.
O :arrow: shelves é o espaço que cada participante do projeto tem para seu uso, seja para experimentar alguma coisa, para testar alguma ideia… Dessa forma você inibe o uso de “versões locais” e oferece backup, versionamente e tudo que um scm oferece.
Eu recomendo o livro “:arrow: Pragmatic Version Control”.
Outras coisas legais em um SCM é o uso correto das tags de versão, (@version $Id$ no meu caso) e um sistema de alerta.
Se você usa MSN no trabalho pode configurar o seu SCM para mandar um alerta a cada commit, se não usa (como eu) e o seu SCM gera um RSS com as mudanças (no caso do Subversion, através do WebSVN) instale um programa na maquina de cada desenvolvedor que dar aqueles alerta tipo “Novo Email” só que baseado em RSS. Funciona bem.
Existem varios desses sistemas de alerta, mas um que está para sair e me parece beeeem legal é o :arrow: www.touchstonegadget.com
Politica de SCM da maioria dos projetos onde eu trabalho aqui na ThoughtWorks eh sempre mais ou menos a mesma: se precisa fazer branch, ta na hora de voltar pra lousa e pensar melhor no assunto e em como estruturar o trabalho.
Alguns projetos fazem uma tag por iteracao, outros quando um story card eh completado (e passou por aprovacao do cliente). Eu prefiro tag-por-release, mas acabei nunca nem tendo que usar tags, entao tudo bem 
Olá ,
porque você acha que branch não são legais ? Estou tendo essa mesma impressão 
Também sou da visão de que branch é exceção, e não regra.
Hoje em dia minha equipe segue a seguinte política:
-Tags sempre que for fechar uma iteração ou release (seguindo um padrão de nomenclatura pré-definido)
-Tags sempre que o programador não estiver confiante com a alteração que vai fazer e quer criar um “ponto de restauração” no repositório. (incentivamos essa prática pois sentimos que dá maior segurança)
-Branches quando é preciso corrigir um erro do sistema que já está em produção. Neste caso cria-se o branch na tag do release em questão, faz-se as correções, cria-se uma nova tag de release, publica-se o resultado e faz-se um merge do repositório.
Resolvemos este problema (e outros) utilizando um arquivo changelog.txt
[quote=s4nchez]
Resolvemos este problema (e outros) utilizando um arquivo changelog.txt [/quote]
É um pouco mais complexo que isso. Eu precisava verificar que o binário que estava rodando (no diretório work) era o certo.
Quanto à branches eu concordo na maioria dos cenários mas quando se trabalha com vários releases isso simplesmente não pode ser feito. Se eu tenho um release A e antes de entregar já tem gente trabalhando no B não pode ser a mesma base de código.
Como ficou:
Acho que isso atende os casos que preciso.
[quote=pcalcado][quote=s4nchez]
Resolvemos este problema (e outros) utilizando um arquivo changelog.txt [/quote]
É um pouco mais complexo que isso. Eu precisava verificar que o binário que estava rodando (no diretório work) era o certo.
[/quote]
Se a idéia é apenas verificar, um arquivo de changelog atualizado com os releases resolve o problema. A única situação que eu consigo imaginar onde é preciso verificar a versão dentro do binário é quando o “circo já pegou fogo” e a equipe tem que provar que o código é aquele mesmo (por favor me corrija se eu estiver errado).
Por que vocês fazem isso?
[quote=s4nchez]
Por que vocês fazem isso?[/quote]
Isto é bem comum em projetos grandes 
[quote=urubatan][quote=s4nchez]
Por que vocês fazem isso?[/quote]
Isto é bem comum em projetos grandes :D[/quote]
A questão é nem porque tem muita gente trabalhando no mesmo projeto, mas sim porque com integrações contínuas e interatividade grande entre os ciclos de desenvolvimento, fazem com que não se perca tempo até serem feitas homologações na release A, pois eles sabem que novas releases irão ser entregues em breve.
[quote=urubatan][quote=s4nchez]
Por que vocês fazem isso?[/quote]
Isto é bem comum em projetos grandes :D[/quote]
Sua resposta foi tão útil quanto se eu perguntasse:
-"Por que as pessoas se queimam no sol?"
E você respondesse:
-“Na praia tem muita gente queimada”
Espero que você possa colaborar mais que isso…