Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • ENSportive Wiki ENSportive Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 11
    • Issues 11
    • List
    • Boards
    • Service Desk
    • Milestones
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • ENSportive
  • ENSportive Wiki ENSportive Wiki
  • Wiki
  • Processos

Last edited by Mateus Campos Caçabuena Jun 29, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Processos

Documentação do negócio

Documentação técnica

Processo de Desenvolvimento

Esta seção é dedicada a apresentar o processo de desenvolvimento do time, com a finalidade de promover organização e padronização para o ambiente de trabalho dos membros da equipe.

Git Workflow

Para nosso desenvolvimento e gerenciamento de código decidimos utilizar o Git Workflow como nosso padrão para controle de versionamento. Git Workflow é um conjunto de práticas e padrões que as equipes de desenvolvimento usam para colaborar em projetos de software usando o sistema de controle de versão Git.

gitflow-1

Nomes das Branches

Para padronizarmos os nomes das branches, deve-se nomeá-las da seguinte forma:

"Id da Issue"-"Descrição Resumida da Feature"

Como por exemplo:

7-get-user-by-id

Assim conseguimos linkar as branches com suas Issues.

Semântica dos Commits

Para padronizarmos a descrição dos commits, será utilizado um padrão semântico a fim de facilitar o compreendimento de cada commit. Os padrões serão os seguintes:

  • feature: Tratam adições de novas funcionalidades ou de quaisquer outras novas implantações ao código;
  • fix: Essencialmente definem o tratamento de correções de bugs;
  • docs: referem-se a inclusão ou alteração somente de arquivos de documentação;
  • test: Adicionando testes ausentes ou corrigindo testes existentes nos processos de testes automatizados (TDD);
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs);
  • refactor: Tipo utilizado em quaisquer mudanças que sejam executados no código, porém não alterem a funcionalidade final da tarefa impactada;
  • style: Alterações referentes a formatações na apresentação do código que não afetam o significado do código, como por exemplo: espaço em branco, formatação, ponto e vírgula ausente etc.);
  • chore: Atualização de tarefas que não ocasionam alteração no código de produção, mas mudanças de ferramentas, mudanças de configuração e bibliotecas que realmente não entram em produção;

Exemplo da descrição commit:

fix: loginError
feature: userLogin

Criando uma Branch

Para criar uma branch e começar a trabalhar nela, 3 comandos git serão essenciais, vejamos abaixo quais são eles:

git checkout develop # Vai para a branch ‘development’.
git pull # Puxa as modificações remotas.
git checkout -b <NOME_DA_SUA_BRANCH_AQUI> # Cria uma nova branch.

Utilizando os comandos acima, você estará indo para a branch ‘develop’, puxando todas as modificações remotas e criando uma nova branch a partir de ‘develop’. Você então passará a trabalhar na nova branch criada.

Definition of Done

Para que uma tarefa seja considerada concluída ela deve seguir as seguintes condições:

  • O merge request da branch em que a tarefa foi desenvolvida para a develop deve ter sido concluída
  • O código deve ter sido revisado e aprovado
  • O código deve ter testes unitários e ter sido testado manualmente
  • O código deve ter documentação para melhor entendimento das mudanças adicionadas (Swagger, descrição no MR, ...)
Clone repository
  • Arquitetura
  • Banco de Dados
  • Configuração
  • Gerência
  • Processos
  • Home
  • mockups
  • sprints