Processo.md
0 → 100644
| | [Home](home) | [Escopo](escopo) | [Processo](processo) | [Design/Mockups](design_mockups) | [Configuração](configuracao) | [Arquitetura](arquitetura) | [Banco de Dados](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 | ||
|  | ||
| 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](https://tools.ages.pucrs.br/plataforma-praxi/plataforma-praxi-wiki/-/wikis/processo) | ||
| --- | ||
| ### ✅ 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: | ||
| ```sh | ||
| <tipoDeItem>/<nomeDoItem> | ||
| ``` | ||
| **Exemplo:** | ||
| ```sh | ||
| 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: | ||
| ```sh | ||
| 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. | ||
| ```sh | ||
| 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.` | ||
| <!-- Mais informações estão disponíveis no link: [Conventional Commits](https://www.conventionalcommits.org/pt-br/v1.0.0/). --> | ||
| ## 〽️ 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. | ||
| --- |