1. Estrutura de Diretorios

O controlde de versoes de sistemas e seus respectivos codigos-fonte é realizado pelo software GIT, seguindo a estrutura braches model onde temos branches prefixados para cada etapa do desenvolvimento de um software, conforme:

master/: Contem, o código que esta atualmente em produção, sempre irá receber o código dos branches de releases quando forem homologados, irá originar branchs de hotfix para correção de Bugs de Produção quando necessário. Somente pessoas do grupo xx-qa tem permissão de escrever neste branch.

development/: Branch de integração do desenvolvimento, a partir dele branches de features serão gerados e irá receber os códigos dos braches das features quando o desenvolvimento das mesmas forem entregues (via Pull Request). Será utilizado pelo analista para validação do desenvolvimento de cada feature entregue pelos desenvolvedores de forma integrada sendo a ultima etapa de validação antes do inicio da homologação. Artefatos gerados neste branch serão publicados no ambiente de desenvolvimento manualmente ou de forma automática. Somente pessoas do grupo xx-qa tem permissão de escrever neste branch. 

feature/: Branch criado exclusivamente para o desenvolvimento de uma feature ou melhoria. Geralmente ele é criado a partir do branch de desenvolvimento (developement) e ao término do trabalho o código é retornado para o branch "developement" (via Pull Request) para ser validado. Este branch só será deletado quando a feature equivalente for para homologação em um determinado branch de release (via Pull Request), ação esta que pode ser executada pela interface de aceite do Pull Request do Stash ou via comando de exclusão de branch do GIT. Somente pessoas do grupo xx-developers tem permissão de escrever neste branch. 

release/: Branch utilizado para homologação de uma determinada versão do software ou projeto. Normalmente este branch nasce a partir do master (produção) e recebe, via merge, código dos branches das features e melhorias a serem homologadas na versão correspondente. Durante a homologação para cada Bug encontrado um novo branch de prefixo Bug deverá ser gerado para o desenvolvedor aplicar a correção, após a correção ele deve solicitar a validação/homologação via Pull Request para o branch de release da versão. Após a versão do branch de release ser homologada o código fonte deve sofre uma TAG e um merge deve ser feito obrigatóriamente para os branchs: development e master e opcionalmente para os branchs de releases abertos se for necessário. Somente pessoas do grupo xx-qa tem permissão de escrever neste branch. 

bugfix/: Branch utilizado para corrigir Bugs encontrados durante a homologação de uma versão dentro de branch de release. Este branch sempre será gerado a partir de um branch de release e após a correção ser desenvolvida o seu código deverá voltar para o branch de release (via Pull Request) para validação e assim sucessivamente até a homologação do Bug. Somente pessoas do grupo xx-developers tem permissão de escrever neste branch. 

hotfix/: Branch utilizado para corrigir um Bug do código da versão que esta em produção (branch master). Após a correção o hotfix deve sofrer merge em um branch de release (versão) já existem ou em um novo branch de release gerado especificamente para homologação do hotfix a partir do branch master (produção). Somente pessoas do grupo xx-developers tem permissão de escrever neste branch.
 

• 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 r.aaaa.mm.dd - versao, onde "r" indica o prefixo de release, "aaaa.mm.dd" representa a data de criacao da tag e "versao" um valor representando a versão logica do projeto frente ao gerenciamento do mesmo; por exemplo "tags/r.20014.05.01 - 1.0.0". 
  Somente pessoas do grupo xx-qa tem permissão de gerar TAGs

2. Fluxo de Promocao de Codigo-fonte de Desenvolvimento ate Producao

A figura abaixo mostra o fluxo de desenvolvimento com branches por tarefas para promoção de artefatos em linha de desenvolvimento, passando por homologação de releases ate entrada em produção e, eventual ajuste corretivo pós-produção.

2.1.1. Caso de Uso

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

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

3. REFERENCIAS

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

http://daptivate.com/archive/2008/08/28/subversion-best-practices-for-web-applications.aspx

http://svn.collab.net/repos/svn/trunk/doc/user/svn-best-practices.html (leitura obrigatoria)

http://stackoverflow.com/questions/570071/subversion-branch-trunk-best-practice-keeping-branch-up-to-date

https://collaborate.txcorp.com/collaborate/support/best-practices-branching-tagging-and-releasing-using-subversion/ (interessante abordagem para integracao continua)

http://svnbook.red-bean.com/en/1.0/ch04s04.html#svn-ch-4-sect-4.1 (dicas de uso do SVN, com enfase para ressurreicao de artefatos)