| ... | ... | @@ -30,123 +30,3 @@ Devem ser apresentados das seguintes formas: |
|
|
|
# Arquitetura Frontend
|
|
|
|
|
|
|
|
Para desenvolvimento do projeto foi escolhido o padrão arquitetural MVP(Model View Presenter) como forma de organização e definição das responsabilidades de cada camada do programa. O padrão MVP foi escolhido por ser uma arquitetura com uma menor curva de aprendizado comparada a arquiteturas que dependem diretamente de conceitos de programação reativa. Além disso, o padrão arquitetural MVP possui uma boa modularização dos componentes e consequentemente uma melhor testabilidade do sistema. |
|
|
|
|
|
|
|
# GitFlow
|
|
|
|
|
|
|
|
Modelo de organização de branches desenvolvido especialmente para o git. Por ser primariamente um modelo de organização de branches, isso significa que o Git Flow estabelece algumas regras de nomenclaturas para tipos de branches enquanto, ao mesmo tempo, define o que cada tipo de branch faz.
|
|
|
|
|
|
|
|
Recomendações para melhor uso do modelo:
|
|
|
|
|
|
|
|
• Projetos em que muitas pessoas vão contribuir.
|
|
|
|
|
|
|
|
• Existe um plano consistente de análise de linha de código.
|
|
|
|
|
|
|
|
• Menor privilégio da velocidade de entrega e mais foco na qualidade.
|
|
|
|
|
|
|
|
• Times pouco experientes ou com grande rotatividade
|
|
|
|
|
|
|
|
• Produtos com o core bem definido e estabelecido
|
|
|
|
|
|
|
|
|
|
|
|
Situações de risco para o modelo:
|
|
|
|
|
|
|
|
• Versões iniciais de produtos
|
|
|
|
|
|
|
|
• Produtos com alto número de mudanças (POC, MVPs)
|
|
|
|
|
|
|
|
• Times bem Srs e experientes pode sentir o gitflow como um gargalo
|
|
|
|
|
|
|
|
## Branches
|
|
|
|
|
|
|
|
**BRANCHES PERMANENTES**
|
|
|
|
|
|
|
|
Branches que vão ser mantidas durante todo o período de desenvolvimento do projeto. Elas devem ser protegidas para manter um histórico de alterações claro e conciso.
|
|
|
|
|
|
|
|
**Master**
|
|
|
|
|
|
|
|
Branch em produção a ser distribuido para as demais branches.
|
|
|
|
Características:
|
|
|
|
|
|
|
|
• Código estável em produção.
|
|
|
|
• código já testado, que será entregue ao cliente
|
|
|
|
|
|
|
|
**Develop**
|
|
|
|
|
|
|
|
A branch de *develop* é criada a partir da master assim que o projeto é iniciado. Sua funcionalidade é fazer a integração das alterações de desenvolvimento que já foram finalizadas. A partir daqui vai ser gerado o ambiente de desenvolvimento e features finalizadas devem enviar suas alterações para a *develop*.
|
|
|
|
Caracteristicas:
|
|
|
|
|
|
|
|
• É onde todo fluxo de trabalho irá ocorrer.
|
|
|
|
|
|
|
|
• Deve sempre conter o código mais atual.
|
|
|
|
|
|
|
|
• É usada para testar as feature.
|
|
|
|
|
|
|
|
• Features finalizadas e prontas.
|
|
|
|
|
|
|
|
|
|
|
|
**BRANCHES TEMPORÁRIAS**
|
|
|
|
|
|
|
|
Branches temporarias devem ser criadas para cumprir um proposito e assim que esse proposito for concluído a branch deve ser apagada.
|
|
|
|
|
|
|
|
**Feature**
|
|
|
|
|
|
|
|
São utilizadas para desenvolver novos recursos para o projeto. Esse tipo de branch é criado a partir da master, quando o novo recurso terminar de ser desenvolvido deve ser enviado para a *develop*.
|
|
|
|
• Demandas, estórias
|
|
|
|
|
|
|
|
• Nomenclatura *feature/descricao_da_tarefa*
|
|
|
|
|
|
|
|
• Desenvolvimento de recursos
|
|
|
|
|
|
|
|
**Bugfix**
|
|
|
|
|
|
|
|
Branch para correção de erros encontrados em produção. Esse tipo de branch tem por objetivo resolver o problema o mais rapidamente possível. Para isso a branch *bugfix* é criada a partir da master e deve ser utilizada para resolver o problema, assim que o problema for resolvido ela deve sofrer um merge para a *master*.
|
|
|
|
Características:
|
|
|
|
|
|
|
|
• Código sempre proveniente da master
|
|
|
|
|
|
|
|
• Nomenclatura *bugfix/descricao_da_tarefa*
|
|
|
|
|
|
|
|
*Obs:***** a descrição da tarefa deve incluir o número da US (airtable).
|
|
|
|
- A cada commit realizado deve ser descrito brevemente, em português, o que foi desenvolvido.
|
|
|
|
- Anexar imagens da tela caso seja um bugfix
|
|
|
|
|
|
|
|
## Ciclo de vida das Branches
|
|
|
|
### Feature
|
|
|
|
|
|
|
|
1. Criar uma nova branch a partir da *master* seguindo a nomenclatura */descricao_da_tarefa*, onde o asterisco representa qualquer cadeia de caracteres.
|
|
|
|
2. Realizar commits na branch afim de desenvolver a funcionalidade.
|
|
|
|
3. Quando a Funcionalidade estiver completa realizar merge com a branch *develop*
|
|
|
|
|
|
|
|
### Bugfix
|
|
|
|
|
|
|
|
1. Criar uma branch a partir da branch master seguindo a nomenclatura *bugfix/descricao_da_tarefa*, onde o asterisco representa qualquer cadeia de caracteres.
|
|
|
|
2. Realizar commits nessa branch com o objetivo de resolver o bug.
|
|
|
|
3. Realizar o merge da bugfix com a branch master
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Gerenciamento de branches no GitLab
|
|
|
|
|
|
|
|
## Criar Pull request
|
|
|
|
Quando finalizamos o desenvolvimento de uma branch e queremos enviar suas alterações para outra branch precisamos criar um pull request. O pull request é uma solicitação de merge que os Ages III e Ages IV vão avaliar para aprovar ou não esse merge. Sendo aprovado e não tendo conflito de commits o merge é feito automaticamente.
|
|
|
|
|
|
|
|
## Aprovação de Pull Request
|
|
|
|
|
|
|
|
Pessoas pertencentes ao grupo de Ages III e Ages IV devem fazer a revisão do código e aprovar os pull request.
|
|
|
|
|
|
|
|
# Ciclo de Vida Gitflow - do PR à Publicação
|
|
|
|
|
|
|
|
Branchs fixas atuais:
|
|
|
|
|
|
|
|
• master
|
|
|
|
|
|
|
|
• develop
|
|
|
|
|
|
|
|
|
|
|
|
PR serão aprovados para as branchs respeitando a nomenclatura definida na imagem abaixo:
|
|
|
|
|
|
|
|
• bugfix/[número da feature] para master
|
|
|
|
|
|
|
|
• feature/[número da feature] para develop
|
|
|
|
|
|
|
|
 |
|
|
\ No newline at end of file |
