|
|
Como regra geral, o código desenvolvido deve passar pelo processo de *build* do Gitlab-CI.
|
|
|
Esse processo tem duas etapas. Testes automatizados e verificação da estrutura do código (*linter*).
|
|
|
|
|
|
## *Linter*
|
|
|
|
|
|
Dentro do repositório existe um arquivo `tslint.json` que contém os padrões de código afotados. É extremantente recomendado que esse *linter* seja habilitado no editor de texto.
|
|
|
|
|
|
O modelo usado é uma extensão dos padrões recomendados para *Typescript* com algumas regras são ignoradas.
|
|
|
|
|
|
O *linter* faz parte do processo de *build*. Logo se o código escrito não atender aos requisitos a build reprovará. Caso o linter não esteja habilitado no editor de texto é possível obter os erros do linter através do comando `npm run lint`.
|
|
|
|
|
|
## Testes
|
|
|
|
|
|
Como padrão de qualidade e para garantir que o Blendb ainda funciona depois que uma *issue* é completada. A princípio em todas as categorias buscamos o máximo possivel, en torno de 90 -95% de cobertura. Normalmente apenas casos de erro muito difíceis de serem testados (como por exemplo falha na conexão com o banco de dados no meio de um proceso) não são testadas.
|
|
|
|
|
|
É importante lembrar que mesmo 100% de cobertura de código não garante a corretude do código. Códigos que envolvem listas e conjuntos, mesmo quando cobertos não representam todas as possibilidades e em caso de uma *build* de sucesso mas erros são encontrados, normalmente listas e conjuntos são as fontes do problema.
|
|
|
|
|
|
Para realizar os testes localmente basta executar o comando `npm test`. Para isso deve-se ter um arquivo no diretório config chamado test.yaml contendo a configuração de teste.
|
|
|
|
|
|
Para obtê-lo basta copiar o arquivo ci_test.yaml.example com o nome test.yaml e estabelescer uma conexão com o banco de dados local (ou em uma máquina de desenvolvimento). Além de modificar a conexão com o banco de dados também se recomenda modificar a opção `struct/create` para falso. Essa opção cria as tabelas no banco de dados de teste. Então quando elas já existem (no caso de o teste ja ter sido executado pela primeira vez) o teste retornrá erro por não conseguir criar as tabelas de fixtures.
|
|
|
|
|
|
## *Branchs*
|
|
|
|
|
|
O *branch* principal do projeto é o branch **master**, a função dele é manter a última versão estável do projeto. Atualmente não existe uma considerada estável, mas assim que existir esse *branch* a mantém.
|
|
|
|
|
|
O *branch* para desenvolvimento é o branch **develop**. Quando uma nova funcionalidade vai ser desenvolvida, deve-se criar um branch a partir do **develop**. Quando ela é concluida um **merge request** deve ser solicitado para o *branch* **develop**. Atualmente o branch **master** faz esse papel mas assim que uma versão estável for criada, o branch **develop** será criado também.
|
|
|
|
|
|
Quando uma nova modificação no código será feita (seja, nova funcionalidade, seja corregão de *bugs*) um branch separado deve ser criado com o nome **issue/{{numero}}** onde o {{numero}} deve ser substiuído pelo numero da tarefa no Gitlab. Se uma tarefa não existe no Gitlab, uma deve ser criada, contendo a razão da modificação e seu numero deve ser utilizado.
|
|
|
|
|
|
É **aconselhado** que ao final de cada dia seja feito um commit com a tag **[WIP]**, para que as mudanças de todos os dias sempre estejam no git, e para informar que a tarefa ainda não foi concluída.
|
|
|
|
|
|
Quando a tag **[WIP]** é usada, pode-se utilizar a tag **[ci-skip]** para não disparar um processo de build. Essa prática também é **aconselhado**.
|
|
|
|
|
|
Cada tarefa deve refletir em exatamente **um** commit quando é realizado um **merge request**. Logo, antes de realizar um merge request, utilize o comando `git rebase -i develop`, e utilize a opção **fixup** para remover os commits até restar apenas **um**.
|
|
|
|
|
|
Esse commit deve ser escrito no seguinte padrão "Issue #{{numero}}: Add/Fix blá blá blá".
|
|
|
Ou seja commits são **sempre** na lingua inglesa. Começam com a palavra *Issue*, seguida da referência para a tarefa no gitlab, seguinda de ": ", um verbo no imperativo e a descrição curta da tarefa (normalmente o título, ou parte dele). |
|
|
\ No newline at end of file |