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