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:

trunk/: Contem, a qualquer momento, o codigo-fonte compilavel do projeto pronto para ser colocado em homologacao. Todos desenvolvedores podem escrever neste diretorio. Sobre este diretorio é executado o servico de Integracao Continua, gerando em intervalos regulares a ultima versao de desenvolvimento disponivel do projeto.

tags/: Sao snapshots do projeto, e uma vez criados nao devem ser alterados. Somente podem escrever neste diretorio usuarios do grupo da qualidade (QA). Por padrao, as tags seguem o formato de nome aaaa.mm.dd - versao, onde "aaaa.mm.dd" representa a data de criacao da tag e "versao" um valor representando a versao logica do projeto frente ao gerenciamento do mesmo; por exemplo "tags/2009.12.01 - versao 0.1" ou entao "2009.12.01 - sprint 44". Existem dois tipos de tag, as tags de entrada "V" (version - com codigo de desenvolvimento para analise e homologacao) e tags de saida "R" (release - com codigo homologado que tanto vai para a producao, quanto volta para o desenvolvimento fazendo merge).

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).

Fluxo de Promocao de Codigo-fonte de Desenvolvimento ate Producao

...

Desenvolvimento diario
1. Programador realizar checkout da pasta trunk/.
2. Programador realizar alteracoes e commits na pasta trunk/.
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/.
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.
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.