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 1
    • Issues 1
    • 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
  • Faladoc.ai
  • WikiWiki
  • Wiki
  • Processo

Last edited by Maurício Gaspary Jun 28, 2024
Page history
This is an old version of this page. You can view the most recent version or browse the history.

Processo

Home Escopo Processo Design/Mockups Configuração Arquitetura Banco de Dados
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

gitflow

Para mantermos os repositórios organizados, utilizaremos o Gitflow, que é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos (feature) ou consertos (hotfix) a partir de duas branches primárias (Main e Development).

  • Main: A branch principal, tendo todo o código final, validado e testado;
  • Development: A branch de desenvolvimento (dev), onde irá organizar os trabalhos realizados.

Mais sobre o Git Workflow


✅ Acceptance Criteria (Critério de Aceitação)

Para que uma tarefa seja considerada pronta, ela deve preencher todos requisitos que estão na task no board de tasks:

🛠️ Padrões Utilizados

Idioma padrão

Todas as branches, commits e merge requests podem ser descritos em português ou inglês.

🔱 Branches

Cada branch relacionada a features/hotfixes será criada a partir da branch development.

Nomes:

Como padrão para nomes de branches, foi decidido que usaremos o CamelCase:

<tipoDeItem>/<nomeDoItem>

Exemplo:

feature/telaDeProcessamento, hotfix/alterTableBanco

Criação:

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

git pull origin dev # Atualiza a branch dev para a versão mais recente

# Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch> # Cria uma nova branch.

# Assim que criar a branch, é necessário fazer um push para garantir que a mesma estará remota:

git push --set-upstream origin <nomeDaBranch>

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

💾 Commits

Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de commit e push.

Para garantir que apenas o código necessário para funcionamento da tarefa será commitado, lembre-se de realizar o comando add apenas nos arquivos essenciais para a tarefa.

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

Em seguida, não esqueça de dar um push para salvar remotamente.

git add <nomeDoArquivo> # Adiciona os arquivos alterados ou criados ao Commit

git commit -m 'descrição da tarefa em português ou inglês' # Salva localmente as alterações com uma descrição obrigatória

# Para commits onde teve participação de mais de um autor. Siga o exemplo abaixo:

git commit -m 'descrição da tarefa em português ou inglês'
Co-Authored-By: Nome Sobrenome <[email protected]>

git push # Salva as alterações remotamente

Tipos de Commit:

  • "feature", para descrever funcionalidades adicionadas;
  • "fix", para descrever soluções de problemas;
  • "docs", para identificar trabalho na documentação do projeto;
  • "build", para identificar trabalho na configuração do projeto.

Exemplos de uso:

  • feature: Implementation of the input button.
  • fix: Correcting the submission of information to the database.
  • docs: Describe commit patterns.
  • build: Dependencies updates.

〽️ Merge Requests

Um merge request (MR) deve ser criado somente quando a tarefa estiver concluída, com critérios de aceitação prontos.

Criação:

A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:

  1. Selecionar a branch de origem (sua branch de desenvolvimento);
  2. Selecionar a branch de destino (branch dev);
  3. Selecione Compare branches and continue;
  4. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
  5. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
  6. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
  7. Na seção Assignee, selecione Assign to me para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
  8. Em Milestone selecione a Sprint em que a tarefa foi realizada;
  9. Em Labels selecione qual é o tipo de tarefa que foi realizada;
  10. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em Submit Merge Request.

❄️ Code Freezing

É estabelecido um tempo onde se encerram os trabalhos de desenvolvimento antes de uma entrega, para garantir a qualidade da entrega, evitando possíveis bugs e problemas que possam surgir.

Foi determinado às 4h da manhã da quinta-feira, antes da entrega.


Clone repository
  • Arquitetura
  • Banco de dados
  • Configuracao
  • Design
  • Escopo
  • Processo
  • Home