[sapl-dev] Melhorias no módulo Parlamentar - SAPL 2.3

[Jean Rodrigo Ferri]

Em 09-05-2011 12:46, Luciano De Fazio escreveu:
> Jean,

Oi Luciano,

> Estive lendo vários documentos sobre conceitos e boas práticas de SVN.
>
> Segundo alguns desses documentos, o conceito de braches importa no
> congelamento do código, ao ser lançada como uma versão, não sofrendo mais
> alterações, mas somente correções, após rigorosos testes de validação,
>
> Não seria interessante aplicar alguma política de "congelamento" dos braches
> ??

Sim, poderia, mas adotamos o modelo de distribuir os sistemas com o 
checkout direto do branch e isso iria dificultar bastante a atualização 
por parte dos usuários pois em vez de eles fazerem um 'svn up' teriam 
que fazer antes um 'svn switch'. Esse 'svn up' é algo que podemos 
colocar em um botão na própria interface de gerenciamento do SAPL.

Não é ruim termos um branch como versão média, desde que combinemos 
entre os desenvolvedores fazer somente correções de erros e pequenas 
implementações, que não tornarão o sistema instável. É claro, antes do 
commit testar bem.

> Por exemplo, após a versão do SAPL 2.3, ninguém mais poderia commitar nesse
> branch, senão o responsável pela validação e exclusivamente correção de
> eventuais bugs.

Problema que com nossa estrutura hoje não temos ainda um time em que 
possamos eleger alguém com o papel de "responsável pela validação". 
Seria ótimo se tivéssemos, seria o Linus Torvalds do SAPL, ou melhor, o 
Marcelo Tosati, pois o Torvalds trabalha no trunk! ;-)

> Isso significaria uma validação mais consistente do código, mantendo-se a
> estabilidade do sistema.
>
> Eventuais melhorias e novas funcionalidades dentro de uma mesma versão
> média, ficariam reservadas somente para as tags (versões menores).

Tags são congeladas, não devem sofrer commits. O próprio nome já diz, 
etiqueta. Elas refletem o software como foi empacotado. É como um ponteiro.

> Assim, o usuário de uma Casa Legislativa teria duas alternativas ao
> atualizar via SVN:
>
> 1- utilizando simplesmente o "svn up", para obter as possíveis correções
> homologadas naquele branch considerado estável / congelado; ou,
>
> 2 -  caso queira obter alguma nova funcionalidade desenvolvida em tags,
> seria necessário reapontar sua cópia de trabalho para depois rodar o "svn
> up".
>
> A adoção desse conceito, traria vantagens como:
>
> - maior controle sobre o código implementado pelos colaboradores da
> comunidade,
>
> - a possibilidade de reapontamento para o branch, em caso de problemas, para
> retorno ao código estável
>
> - a garantia de que o branch será realmente estável.

Isso é interessante, mas a maneira como o SAPL está sendo distribuído é 
um pouco diferente disso devido ao checkout do branch. Mudar isso agora 
em todos os SAPLs dará um trabalhão. E como está tem funcionado bem, 
desde que lembremos de não quebrar o branch.

Mas o que eu gostaria de lembrar, e às vezes o pessoal esquece, que um 
sistema de versionamento permite sempre que façamos checkouts e updates 
a versões específicas do código, ao longo de sua linha do tempo. Assim, 
podemos utilizar: 'svn update -r 2298' para atualizar para trás, ou 
seja, voltar a cópia de trabalho à revisão 2298.

O mesmo vale para a maioria dos comandos do Subversion, como por exemplo 
o checkout: 'svn checkout -r 3332 
http://repositorio.interlegis.gov.br/ILPortalCasas/branches/1.1'.

Isso significa que um branch, que é na verdade um fork, poderá variar de 
acordo com a revisão que utilizamos. Se fez um update e quebrou, é 
possível fazer um novo update da revisão anterior. Daí a não necessidade 
de se marcar o branch com a versão menor. No caso do SAPL, o branch terá 
acesso a todas as correções e alterações ao longo da vida daquele fork. 
E a Tag vai etiquetar onde ocorreu a passagem de uma versão menor para a 
outra, por exemplo: 2.3.1 -> 2.3.2

E, é claro, não podemos esquecer de após fazer um commit no branch, 
sempre fazer o devido backport para o trunk, e, se necessário, para os 
branchs mais novos.

Bom, é assim que funciona hoje, se quiserem poderemos mudar.

Abraço,

-- 
Jean Ferri
Analista de Sistemas
Interlegis - Brasília (DF)