...

Controle de versões de sistemas

O controlde de versoes de sistemas e seus respectivos codigos-fonte é realizado pelo software Subversion, seguindo a estrutura classica de branches, tags e trunk, conforme:

...

• branches/: Sao usados para trabalhos esporadicos para de correcao de codigo de producao ativo ou antigo. Todos podem escrever aqui. Para cada correcao, um branche novo eh criado a partir de uma tag "R" de producao (a ultima ou uma antiga). A correcao (commits) ocorrem aqui ate que o codigo possa ser homologado. Nesse caso, a equipe de QA copia esse codigo para uma nova tag "V" e o ciclo de homologacao acontece, ate que uma tag "R" seja produzida. Se o branche de correcao equivaler ao ultimo codigo de producao (ativo), entao a saida do codigo "R" deve voltar para o desenvolvimento (merge), caso contrario, eh facultativo esse retorno para o desenvolvimento (uma vez que era uma versao antiga do software, talvez esse problema ja tenha sido trabalhado no fluxo trunk/, ou mesmo esse problema nao ocorre nas versoes mais novas ou ativa do sistema).

Casos de Uso

Indicam, cada um, os principais processos relacionados ao gerenciamento de codido-fonte e artefatos produzidos pela equipe de desenvolvimento:

Caso de uso: Promocao de codigo fonte de desenvolvimento ate producao

Premissas

1. Todo o desenvolvimento ocorre na pasta trunk/ do projeto.
2. Existe integração contínua diária automática na pasta trunk/.
3. Commits na pasta trunk/ não podem quebrar a compilação do projeto.
4. Toda equipe de desenvolvimento pode realizar commits na pasta trunk/.
5. Existe um branche de homologação, chamado hml/.
6. Existe integração contínua no branche de homologação, que é iniciada manualmente pelo homologador do sistema no momento de iniciar um novo processo de homologação.
7. O branche de homologação visa conter código de estabilização e validações finais antes da entrada de produção.
8. Todo codigo de homologação deve ser marcado (tageado) na sua entrada (com a tag "v") e na sua saída (com a tag "r").
9. O código de homologação é proveniente do código de desenvolvimento, devidamente tageado.
10. Toda homologação de sucesso deve gerar uma tag "r", que visa marcar código estavel para entrada em produção.
11. Existe um branche de produção, chamado prod/.
12. Não existe integração contínua para código de produção.
13. O branche de produção visa conter código de produção, efetivamente validado pela homologação.
14. Os unicos commits validos no branche de produção deve ser os relativos ao processo de merge, proveniente da tag "r".
15. Na eventualidade de existir correcoes em codigo de producao, um branche especifico deve ser criado.
16. A finalizacao de uma correcao de producao no branche relacionado deve ser encerrada com uma tag "r" e, a partir disso, um processo de "build" manual deve ser realizado.

Fluxo Principal

1. Desenvolvimento diario
   1. Programador realizar checkout da pasta trunk/.
   2. Programador realizar alteracoes e commits na pasta trunk/.
2. Promocao para homologacao (equipe e usuarios acordar momentos adequados, exemplo, a cada 15 dias)
   1. QA criar tag "v", marcando o incio de revisao de homologacao.
   2. QA copiar ultima versao da pasta trunk/ para dentro da tag "v".
   3. QA apagar conteudo da pasta hml/.
   4. QA copiar conteudo da tag "v" para dentro da pasta hml/
   5. QA realizar checkout da pasta hml/.
   6. QA realizar testes unitarios e integrados, alteracoes corretivas e commits na pasta hml/, se necessario.
   7. QA invocar integracao continua da homologacao.
   8. Usuario testar funcionalmente aplicacao em ambiente de homologacao.
   9. Repetir 08 até encerrar o ciclo de correções.
   10. Usuario protocolar aceite de homologacao.
   11. QA atualizar arquivo "release-notes" do projeto na pasta hml/.
   12. QA realizar commit final de revisao de homologacao na pasta hml/.
3. Promocao para producao
   1. QA criar tag "r", marcando o fim de revisao de homologacao.
   2. QA apagar conteudo da pasta prod/.
   3. QA copiar conteudo da pasta "r" para dentro da pasta prod/.
   4. QA comunicar Administrador de nova versao de producao disponivel.
   5. Administrador realizar deployment de producao.
4. Reintegracao de desenvolvimento
   1. QA realizar checkout da pasta trunk/.
   2. QA realizar merging da pasta hml/ para pasta trunk/ local.
   3. QA resolver conflitos na pasta trunk/ local.
   4. QA realizar commits de resolucao de conflitos na pasta trunk/.
   5. Programador realizar update na pasta trunk.

REFERENCIAS

http://svnbook.red-bean.com/en/1.0/ch04s04.html#svn-ch-4-sect-4.1

...