O Scratch Out é uma aplicação móvel em desenvolvimento com o propósito de aumentar produtividade dos seus usuários, indicando pontos de melhorias nas suas rotinas e tarefas.
| Atividades | Inicio | Término Previsto | Data de Conclusão |
|---|---|---|---|
| Referencial Teórico | 08/08/2018 | 08/08/2018 | |
| Diagrama de Casos de Uso | 08/08/2018 | ||
| Diagrama de Atividades | 15/08/2018 | ||
| Wireframe | 22/08/2018 | 08/09/2018 | |
| DER & MER | 29/08/2018 | ||
| Diagrama de Classes | 29/08/2018 | ||
| Banco de Dados | 10/10/2018 | ||
| Diagrama Sequência | 18/09/2018 | 05/09/2018 | |
| Desenvolvimento Front-end | 17/10/2018 | ||
| Desenvolvimento Back-end | 17/10/2018 | ||
| Feira Tecnológica | 16/10/2018 | 19/10/2018 | |
| Teste da Aplicação | 31/10/2018 | 09/11/2018 | |
| Defesa | 23/11/2018 |
Está parte é voltada para o método correto de usar o GitHub no projeto, onde será aplicado as regras das Branches e como as usar de maneira correta.
Ao trabalhar com um time de desenvolvimento em um sistema, é comum termos diversos membros trabalhando em uma mesma funcionalidade ou termos que alterar uma funcionalidade já dada como pronta - arrumar bugs, por exemplo. Para evitar avacalhar com algo que já está pronto, podemos criar um branch. Um branch serve como uma caixa de areia, criando uma cópia do estado atual do repositório onde se pode alterar sem a preocupação de estragar uma parte importante do sistema. Uma vez que as alterações propostas em um branch estiverem testadas e funcionando, é possível realizar a operação merge com o branch "original", ou seja, inserir as alterações na versão estável da funcionalidade.
Para devs, testers e demais membros do time, segue algumas explicações sobre o esquema de branches e deste repositório em geral:
- O branch master nunca deve ser alterado diretamente. Nele está/estará contido a versão estável do sistema, que ja foi aprovada
- O branch development deve ser o ambiente onde as alterações feitas nos demais branches sejam aplicadas para testes para serem aprovadas para ir a branch 'master' . Uma vez que tais modificações sejam aprovados nos testes, poderá ser realizado um merge desse branch('development') com o 'master'.
- O branch feature/
São branches nas quais serão desenvolvidos e implementados novos recursos (Stories/Issues). Essas branches têm o nome começando com feature/* (exemplo: feature/login) e são criadas a partir da branch development. Ao término do desenvolvimento da feature em questão, esta branch será mesclada com a development e em seguida apagada. - O branch hotfix/
São branches nas quais são realizadas correções de bugs críticos encontrados no código em nível de produção, e que por isso são criadas a partir da branch master, e após correções são juntadas diretamente com a branch master, para que a versão atual seja corrigida, e com a branch development e a _branch release/, para que essa correção persista para as próximas versões. Essas branches têm o nome começando com hotfix/ e terminando com o próximo sub-número de versão (exemplo: hotfix/2.31.1); Seguindo a nomenclatura de versionamento, abaixo. - O branch release/
São branches com um nível de confiança maior do que a branch _development_e a última chance de identificar e corrigir algum bug antes de ir para a branch master. Estas se encontram em nível de preparação para ser juntada com a branch master e com a branch development(para caso tenha ocorrido alguma correção de bug na branch release/* em questão). Essas branches têm o nome começando com release/ e terminando com o número da próxima versão do software (seguindo o exemplo do hotfix, dado acima, seria algo como release/2.32.0).
Basicamente, a hierarquia de branchs é a seguinte:
master <-- release/ <-- development <-- feature/ feature2. Tendo ainda a hotfix/ ligada diretamente a master, release e development.
"Versão X.Y.Z", onde X,Y e Z são números positivos representando, respectivamente: Projeto, Features, Bugfix. Ou seja, esta >primeira versão do ScratchOut, Feature 12, correção do quarto bug achado ficaria: "Versão 1.12.4"
Atualização de Conteúdo 1.12.4 -- ScratchOut Eduardo - 18/09/2018
- Lista de conteúdo adicionado sem termos muito técnicos, será a visualização para o usuário final.
- Lista de conteúdo adicionado com termos técnicos,será usado para o entendimento da equipe no que foi realmente alterado ou adicionado.
- Relatar bugs e problemas que já foram encontrados e respectivamente corrigidos.
- Relatar bugs encontrados que ainda não foram corrigidos, caso o bug seja critico é aconselhável que seja corrigido imediatamente.