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
This is an old version of this page. You can view the most recent version or browse the history.

Processo

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

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