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
  • Processo

Last edited by Dylan Souza Silveira Nov 24, 2024
Page history

Processo

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

Processo de Desenvolvimento

Descrição

Esta seção é dedicada a apresentar o processo de desenvolvimento de código.

Sumário

  • Git Workflow

Git Workflow

gitflow

Gitflow

O Gitflow é um modelo alternativo de ramificação do Git que consiste no uso de ramificações de recursos (features) e várias ramificações primárias (main e develop). Todas as novas branchs de desenvolvimento devem ser criadas abaixo da develop.

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

Merge Requests

Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:

Criando o Merge Request

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 Labelsselecione 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.

Revisando o Merge Request

A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na dev.

Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a funcionalidade/bug/componente/tela de acordo com os critérios de aceitação apresentados no Trello.

Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.

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