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, junto dela serão apresentados documentos referentes a maneira como o time se organizou e trabalha.

Git Workflow

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.

O Git é uma ferramenta poderosa que permite que os desenvolvedores trabalhem juntos em um mesmo código-fonte sem causar conflitos ou perder trabalho. O Git workflow estabelece uma estrutura para como as alterações no código são gerenciadas, revisadas e implementadas, a fim de garantir que o projeto progrida de maneira organizada e eficiente.

Nomes das Branches

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

<UserStory>-<Descrição>

Como por exemplo:

US04-add-login

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);
  • build: Alterações que afetam o sistema de construção ou dependências externas (escopos de exemplo: gulp, broccoli, npm),
  • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs);
  • perf: Uma alteração de código que melhora o desempenho;
  • 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

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
  • Qualquer documentação necessária deve ter sido escrita (payloads, endpoints, ...)

Code freezing

Code freezing é uma data para congelamento de entrada de código em produção. Após essa data, nenhum merge request será mais aceito. A única coisa que pode passar por esse bloqueio são hotfixes para erros em produção

Definition of Ready

Para que uma tarefa seja considerada pronta para desenvolvimento, ela deve seguir as seguintes condições:

  • Qualquer tarefa da qual ela tenha dependência
  • O ambiente de desenvolvimento local deve estar devidamente setado
Clone repository
  • Arquitetura
  • Banco de Dados
  • Configuração
  • Gerência
  • Processos
  • Home
  • mockups
  • sprints