crossBILLy

crossBILLy - Michael Alekseew

@alekseew/ crossBILLy

Este repositório contém um aplicativo Web e multiplataforma (Web PWA, Windows, Mac OS X, iOS e Android) para fácil geração de faturas. Este projecto deverá ajudar a manter os dados dos clientes, fazer a facturação/facturação,...

Frameworks, plataformas, bibliotecas, plugins, conceitos, arquiteturas, técnicas, usados ​​ou testados, ... são os seguintes:

• Modelo de ramificação de controle de origem: GitFlow
• Plataforma/estrutura Frontend WebApp: Angular
• Ferramenta/estrutura de construção de plataforma cruzada: capacitor iônico ou Cordova e elétron
• Linguagem de desenvolvimento: Typescript / ( JavaScript )
• Biblioteca de interface do usuário WebApp: material angular
• Biblioteca de "comportamento" da UI do WebApp: Angular CDK
• Formatação de código: mais bonita
• Versionamento, Changelog automático (lançamentos): Versão Padrão
• Ferramenta de confirmação de mensagens: Commitizen
• Ferramenta Git-Hooks: Husky
• Animações: Lottie e Lottie-Web
• Hospedagem e muito mais...: FireBase
• Integração Contínua (CI) / Testes e Construções: Travis
• Monitoramento de dependência: Greenkeeper
• vai continuar...

Pré-requisitos

Este projeto requer que as seguintes dependências sejam instaladas previamente:

• Node.js
• NPM

Dependências

Para instalar todas as dependências necessárias basta executar:

npm install

Isso também configura o modelo de mensagem de commit do git (e define o pacote wip para usar commitzen).

GitFlow

Por favor, use o modelo de ramificação GitFlow e os nomes padrão para as ramificações do SourceTree neste projeto. Mais informações podem ser encontradas aqui:

• GitFlow
• SourceTree + GitFlow

Convenção de nomenclatura de nomes de ramificações e prefixos (configuração padrão no SourceTree):

• Ramo de produção: mestre
• Ramo de desenvolvimento: desenvolver
• Prefixo da ramificação do recurso: recurso/
• Prefixo do branch de lançamento: release/
• Prefixo da ramificação do hotfix: hotfix/
• Sem prefixo de tag de versão (os nomes das tags serão, por exemplo, v0.1.0)

Log de alterações/commits convencionais

Neste projeto (angular) commits convencionais são usadas Diretrizes de mensagens de commit angular .

Eles serão usados ​​para gerar automaticamente o changelog com o pacote npm standard-version , para isso basta executar npm run release . Isso fará a seguinte tarefa:

• Atualizar a versão do projeto
• Gere/atualize o CHANGELOG.md
• Confirme essas alterações (pronto para enviar para remoto)
• Gere uma tag git

Você pode usar npm run commit para obter um assistente que o ajude a escrever as mensagens de commit corretas (isso é feito com commitizen ).

Além disso, as mensagens de commit serão verificadas se estão corretas com commitlint (se você realmente precisar ignorá-lo, você pode ignorar os githooks, mas não deve fazer isso normalmente).

Você pode gerar um modelo de mensagem de commit do git com npm run prepare-git-commit-template , isso também será feito durante a instalação do npm.

Formato de mensagem de confirmação

O cabeçalho (consiste em type , scope e subject ) não deve ter mais de 72 caracteres.

 type(scope?): subject

body?

footer?

Tipo

Deve ser um dos seguintes:

• talento : Um novo recurso
• correção : uma correção de bug
• docs : Apenas a documentação muda
• style : Alterações que não afetam o significado do código (espaço em branco, formatação, falta de ponto e vírgula, etc.)
• refatorar : uma alteração de código que não corrige um bug nem adiciona um recurso
• perf : Uma alteração de código que melhora o desempenho
• test : Adicionando testes ausentes ou corrigindo testes existentes
• build : alterações que afetam o sistema de compilação, configuração de CI ou dependências externas (escopos de exemplo: gulp, brócolis, npm)
• ci : Alterações em nossos arquivos e scripts de configuração de CI (escopos de exemplo: Travis, Circle, BrowserStack, SauceLabs)
• chore : outras alterações que não modificam arquivos src ou test
• reverter : Reverte um commit anterior

Escopo

O escopo pode ser qualquer coisa que especifique o local da alteração do commit. Estou usando as seguintes convenções (exemplos):

• all : alterações para todo o projeto (lançamento geral do projeto, ...)
• root : alterações na raiz (pasta) do projeto
• be : mudanças na parte backend do projeto
• fe : mudanças na parte frontend (webapp) do projeto

Assunto

O assunto contém uma descrição sucinta da mudança:

• use o imperativo, presente: "mudar" e não "mudar" nem "mudar"
• não coloque a primeira letra em maiúscula
• sem ponto (.) no final

Corpo

Assim como no sujeito , use o imperativo, presente: “mudar” e não “mudou” nem “muda”. O corpo deve incluir a motivação para a mudança e compará-la com o comportamento anterior.

Rodapé

O rodapé deve conter qualquer informação sobre alterações significativas e também é o local para fazer referência aos problemas do JIRA que este commit fecha .

Breaking Changes deve começar com a palavra BREAKING CHANGE: com um espaço ou duas novas linhas. O resto da mensagem de commit é então usado para isso.

Ganchos de commit

Neste repositório, ganchos git são usados ​​(configurados com husky ) para verificar o código-fonte "limpo".

Verificação de formato mais bonita

Se os arquivos Typescript ou SCSS forem alterados e enviados, um gancho de confirmação será acionado e os arquivos preparados serão formatados com mais beleza. Ele faz a formatação/alterações e confirma e envia essas alterações, com a ajuda de arquivos .

Confirmar mensagem Linting

Verifica se a mensagem de commit do git é uma mensagem de commit convencional do git, caso contrário cancelará o commit.

Versão e lançamento do projeto

O último commit no branch release deve definir a versão do projeto e gerar o Changelog, isso deve ser feito com npm run release . Este conjunto é a versão do projeto , gera o changelog e confirma essas alterações . Mais informações podem ser encontradas no capítulo: Changelog / Commits Convencionais

Continua integração e implantação

Neste projeto, o Travis CI está configurado como lint-, test-, e2e-tests- e build-slave. Se tudo foi testado e construído com sucesso, o Travis CI implantará o WebApp no ​​FireBase .