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
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 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); - Em
Milestone
selecione a Sprint em que a tarefa foi realizada; - Em
Labels
selecione 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.