Página da Arquitetura do Sistema

Esta é a página onde irá ficar todas as informações da Arquitetura do seu projeto, Como:

• Segurança
• Rotas de Backend (Arquitetura funcional)
• Objects – Backend API
• Methods – Backend API
• Arquitetura Não Funcional)
• Diagrama de Pacotes / Componentes (Arquitetura de software)
• Diagrama de Deploy
• Documentação sobre aplicação de Design do Projeto
• Análise dos principios SOLID
• Code Review

Devem ser apresentados das seguintes formas:

• Imagens ou Gifs
• Diagramas ou Sistemas
• Descrições ou Textos explicativos

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