| 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
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:
- Selecionar a branch de origem (sua branch de desenvolvimento);
 - Selecionar a branch de destino (branch dev);
 - Selecione 
Compare branches and continue - Em 
Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido; - Em 
Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados; - Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
 - Na seção 
Assignee, selecioneAssign to mepara 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); - Em 
Milestoneselecione a Sprint em que a tarefa foi realizada; - Em 
Labelsselecione qual é o tipo de tarefa que foi realizada; - 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.
