Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reverted from v. 11
Numbered Headings
Info
titleNesta pagina
Excerpt

Informacao passo-a-passo sobre o processo de homologacao de artefatos existentes dentro do repositorio versionado.

Note
titleUsuarios DVCS

O procedimento mostrado aqui eh baseado no uso do software GITSubversion, um gerenciador de controle de versão com repositórios distribuídosclassico repositorio cliente-servidor.
Caso voce voce utilize um repositorio centralisado distribuido (DVCS) como SVNMercurial, TFS Git ou outro, talvez este processo nao seja o mais adequado para voce.

Tip
titleVeja tambem

Versionamento de Artefatos para informacoes sobre o controle de numeracao de artefatos versionados.

Estrutura de Diretorios

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

  • trunk/: 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.

Image Removeddevelopment/: 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. 

Image Removedfeature/: 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. 

Image Removedrelease/: 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. 

Image Removedbugfix/: 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. 

Image Removedhotfix/: 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.
 

  • 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 r.nome 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 versao logica do projeto frente ao gerenciamento do mesmo; por exemplo "tags/r2009.2001412.05.01 - versao 0.1" ou entao "2009.0.0". 
    Somente pessoas do grupo xx-qa tem permissão de gerar TAGs12.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

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

Image Removed

Image Added

Caso de Uso

Objetivo

Realizar todo o fluxo de criacao, alteracao e remocao de codigo-fonte ate entrada em producao, habilitando pontos de checagem para posterior volta de versao.

Ator principal

QA

Atores envolvidos

Desenvolvimento, Usuario, Administador

Resumo

Seguir o fluxo de operacoes: trunk/ (commits de desenvolvimento) > tag "v" (copia do trunk) > hml/ (commits de qualidade) > tag "r" (copia da homologacao) > (merge para desenvolvimento) trunk/ & (copia para producao) prod/ > (branche para correcao) > tag "r".

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

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)