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