Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
blendb
blendb
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 23
    • Issues 23
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 1
    • Merge Requests 1
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • C3SL
  • blendbblendb
  • Wiki
    • Desenvolvimento
  • padrões

Last edited by Lucas Fernandes de Oliveira Dec 04, 2017
Page history

padrões

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

Home

  • Estrututura do repositório
  • Padrões de projeto
  • Padrões da documentação
  • Tecnologias utilizadas
  • Arquivo de configuração
Clone repository
  • algoritmos
  • algoritmos
    • agregações
    • consultas
  • api
  • api
    • dados
    • introdução
    • metadados
    • outros
    • usos
  • desenvolvimento
  • desenvolvimento
    • configuração
    • documentação
    • padrões
    • repositório
    • repositório
      • artwork
View All Pages