|
|
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*).
|
|
|
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.
|
|
|
Dentro do repositório existe um arquivo chamado `tslint.json` que contém os padrões de código adotados. É 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 modelo usado é uma extensão dos padrões recomendados para *Typescript* com algumas regras 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`.
|
|
|
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.
|
|
|
Como padrão de qualidade e para garantir que o Blendb ainda funcione depois que uma *issue* é completada.
|
|
|
A princípio em todas as categorias buscamos o máximo possivel, em torno de 90-95% de cobertura.
|
|
|
Normalmente, apenas erros muito difíceis de serem testados não são incluídos na bateria de testes, como falhas na conexão com o banco de dados no meio de um processo, por exemplo.
|
|
|
|
|
|
É 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.
|
|
|
É 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 contendo erros, provavelmente as 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.
|
|
|
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 estabelecer 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 é recomendado 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 já ter sido executado pela primeira vez) o teste retornará 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.
|
|
|
A *branch* principal do projeto é a branch **master**, a função dela é manter a última versão estável do projeto. Atualmente não existe uma considerada estável.
|
|
|
|
|
|
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.
|
|
|
A *branch* para desenvolvimento é a branch **develop**. Antes de iniciar uma nova funcionalidade, deve-se criar uma branch a partir da **develop** para realizar as alterações. Quando ela é concluida, um **merge request** deve ser solicitado para a *branch* **develop**. Atualmente, o branch **master** faz esse papel.
|
|
|
|
|
|
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.
|
|
|
Quando uma modificação no código será feita, seja nova funcionalidade ou corregão de *bugs*, deve ser criada uma nova branch com o nome **issue/{{numero}}** onde o {{numero}} deve ser substituído pelo número 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 número 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**.
|
|
|
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 é **aconselhada**.
|
|
|
|
|
|
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**.
|
|
|
Cada tarefa deve refletir em exatamente **um** commit na develop. 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).
|
|
|
Isto é, commits são **sempre** na língua inglesa. Começam com a palavra *Issue*, seguida da referência para a tarefa no GitLab, seguida de ": ", um verbo no infinitivo e a descrição curta da tarefa (normalmente o título ou parte dele).
|
|
|
|
|
|
|
|
|
## [Home](/)
|
... | ... | |