Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Wiki Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • MeditAmamente
  • WikiWiki
  • Wiki
  • Arquitetura

Last edited by Dylan Souza Silveira Nov 24, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Arquitetura

Home Escopo Gerência Processo Mockups Configuração Arquitetura DataBase Infraestrutura

Arquitetura e Métodos Utilizados

GitFlow

O que é?

GitFlow é o processo de contribuição para os projetos que fazem uso da ferramenta Git. As definições presentes neste documento se aplicam tanto para o repositório de frontend quando para o repositório de backend.

Branches protegidas:

As branches "main" e "develop" não devem ser apagadas e possuem regras de proteção específicas para garantir que apenas usuários com papéis específicos possam realizar certas alterações:

main

É a branch principal do projeto. Esta branch deve sempre conter o código rodando no ambiente de produção, sem bugs. A branch é protegida e só pode ser alterada a partir de Merge Requests (MRs) vindo diretamente da branch develop. Apenas AGES III e IV podem realizar o merge dos MRs e realizar alterações nessa branch.

develop

É a branch para desenvolvimento, onde o código é continuamente atualizado e onde são realizados todos os MRs. Esta deve ser a branch de partida de todas as outras branches do projeto. Essa branch é protegida, o que significa que as alterações só podem ser feitas através de Merge Requests. Qualquer usuário com acesso ao projeto pode criar um MR para esta branch.

Branches não protegidas (feature/fix/update):

Feature: branches para implementação de funcionalidades novas.

Fix: branches para correção de bugs.

Update: branches para atualizações.

Todos os MRs dessas branches devem sempre ser abertos para develop.

Nomenclatura padrão para criação de branches:

tipo_da_branch/numero_da_us/o_que_sera_feito

exemplo: feat/us1/botao-login

Como posso criar uma branch?

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch develop antes de criar uma branch nova:

git pull origin dev

Este comando garante que você esteja trabalhando com a versão mais atualizada do projeto. Depois, para criar a nova Branch na qual você realizará sua tarefa, execute o comando:

git checkout -b feature/<nomeDaBranch>

Após a criação da branch, é necessário usar o comando `push` para publicar sua branch:

git push --set-upstream origin feature/<nomeDaBranch>

Pronto! Agora você já pode começar a programar na sua Branch.

Commits

Para garantir que o commit a ser realizado terá apenas o código necessário para funcionamento da tarefa, use o comando add apenas nos arquivos essenciais para a tarefa:

git add <nomeDoArquivo>

Depois de adicionar todos os arquivos que deseja commitar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:

git commit -m 'descrição da tarefa'

Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso, use o comando push:

git push

O padrão das mensagens de commit devem seguir o padrão especificado abaixo:

Diagrama de Deploy

Diagrama de Componentes

Modelo da Arquitetura usada no Front-end

Para a arquitetura de desenvolvimento do Front-end da aplicação, foram criadas as seguintes pastas:

modules: Essa pasta contém todas as dependências do projeto, instaladas via npm ou yarn. Essas bibliotecas são necessárias para o funcionamento do projeto.

public: Essa pasta armazena arquivos estáticos, como imagens e fontes.

src: Pasta com o código-fonte principal do projeto. Dentro dela, a pasta app organiza outras pastas de acordo com diferentes responsabilidades:

  1. @types: Usada para definir tipos TypeScript personalizados ou declarações de tipos para bibliotecas que não têm definições de tipos embutidas.

  2. api: Ficam as chamadas e configurações de APIs, incluindo funções para comunicar-se com backends ou serviços externos.

  3. data: Usada para armazenar dados brutos ou constantes que podem ser usados em toda a aplicação. Isso pode incluir arquivos JSON ou outras formas de dados estruturados.

  4. theme: Armazena arquivos relacionados ao tema da aplicação, como configurações de cores, tipografia e outros estilos globais.

  5. presentation: Esta pasta organiza os componentes de apresentação, ou seja, as partes da interface de usuário (UI). Dentro dela:

    5.1. components: Ficam os componentes reutilizáveis da UI, como botões, formulários, modais, etc.

    5.2. hooks: Código para adaptar a mesma página para diferentes tamanhos de tela, tornando a interface mais flexível e responsiva.

    5.3. pages: Representam as diferentes páginas da aplicação. Cada arquivo dentro dela se torna uma rota da aplicação.

Modelo da Arquitetura usada no Back-end

Clone repository
  • Arquitetura
  • Configuração
  • Database
  • Escopo
  • Gerência
  • Infraestrutura
  • Mockups
  • Processo
  • Testes
  • Home