crossBILLy

crossBILLy - Michael Alekseew

@alekseew/ crossBILLy

Ce référentiel contient une application Web et multiplateforme (Web PWA, Windows, Mac OS X, iOS et Android) pour une génération facile de factures. Ce projet devrait permettre de maintenir les données clients, de faire la facturation/facturation, ...

Les frameworks, plateformes, bibliothèques, plugins, concepts, architectures, techniques, utilisés ou testés, sont les suivants :

• Modèle de branchement de contrôle de source : GitFlow
• Plateforme/Framework Frontend WebApp : Angulaire
• Outil/cadre de construction multiplateforme : condensateur ionique ou Cordova et électron
• Langage de développement : Typescript / ( JavaScript )
• Bibliothèque d'interface utilisateur WebApp : matériau angulaire
• Bibliothèque « Comportement » de l'interface utilisateur WebApp : CDK angulaire
• Formatage du code : plus joli
• Gestion des versions, journal des modifications automatique (versions) : version standard
• Outil de message de validation : Commitizen
• Outil Git-Hooks : Husky
• Animations : Lottie & Lottie-Web
• Hébergement et plus encore... : FireBase
• Intégration continue (CI) / Tests et builds : Travis
• Surveillance des dépendances : Greenkeeper
• va se poursuivre....

Conditions préalables

Ce projet nécessite que les dépendances suivantes soient installées au préalable :

• Noeud.js
• MNP

Dépendances

Pour installer toutes les dépendances nécessaires, exécutez simplement :

npm install

Cela configure également le modèle de message git commit (et configure le package wip pour qu'il utilise commitizen).

GitFlow

Veuillez utiliser le modèle de branchement GitFlow et les noms par défaut pour les branches de SourceTree dans ce projet. Plus d'informations peuvent être trouvées ici :

• GitFlow
• Arbre Source + GitFlow

Convention de dénomination des noms de branches et des préfixes (paramètre par défaut dans SourceTree) :

• Branche de production : master
• Branche de développement : développer
• Préfixe de branche de fonctionnalité : feature/
• Préfixe de branche de version : release/
• Préfixe de branche du correctif : correctif/
• Pas de préfixe de balise de version (les noms de balises seront par exemple v0.1.0)

Journal des modifications / validations conventionnels

Dans ce projet (angulaire), les directives de message de validation angulaire conventionnelles sont utilisées.

Ils seront utilisés pour générer automatiquement le journal des modifications avec la version standard du package npm. Pour ce faire, exécutez simplement npm run release . Cela effectuera la tâche suivante :

• Mettre à jour la version du projet
• Générer/mettre à jour le CHANGELOG.md
• Validez ces modifications (prêt à transmettre à distance)
• Générer une balise git

Vous pouvez utiliser npm run commit pour obtenir un assistant qui vous aide à écrire les messages de validation corrects (cela se fait avec commitizen ).

De plus, les messages de validation seront vérifiés pour s'assurer qu'ils sont corrects avec commitlint (si vous avez vraiment besoin de l'ignorer, vous pouvez contourner les githooks, mais vous ne devriez pas le faire normalement).

Vous pouvez générer un modèle de message git commit avec npm run prepare-git-commit-template , cela sera également fait lors de l'installation de npm.

Format du message de validation

L’ en-tête (composé de type , scope et subject ) ne doit pas dépasser 72 caractères.

 type(scope?): subject

body?

footer?

Taper

Doit être l'un des éléments suivants :

• exploit : Une nouvelle fonctionnalité
• correctif : une correction d'un bug
• docs : la documentation modifie uniquement
• style : Modifications qui n'affectent pas la signification du code (espace blanc, formatage, points-virgules manquants, etc.)
• refactor : Un changement de code qui ne corrige pas de bug ni n'ajoute de fonctionnalité
• perf : Un changement de code qui améliore les performances
• test : Ajout de tests manquants ou correction de tests existants
• build : Modifications qui affectent le système de build, la configuration du CI ou les dépendances externes (exemples de scopes : gulp, broccoli, npm)
• ci : Modifications apportées à nos fichiers de configuration et scripts CI (exemples de scopes : Travis, Circle, BrowserStack, SauceLabs)
• corvée : Autres modifications qui ne modifient pas les fichiers src ou test
• revert : annule un commit précédent

Portée

La portée peut être n'importe quel endroit spécifiant le changement de validation. J'utilise les conventions suivantes (exemples):

• all : modifications pour l'ensemble du projet (version générale du projet, ...)
• root : changements dans la racine (dossier) du projet
• be : changements dans la partie backend du projet
• fe : changements dans la partie frontend (webapp) du projet

Sujet

Le sujet contient une description succincte du changement :

• utilisez l'impératif, au présent : "changer" et non "changé" ni "changements"
• ne mets pas de majuscule à la première lettre
• pas de point (.) à la fin

Corps

Tout comme dans le sujet , utilisez l'impératif, au présent : « changement » et non « changé » ni « changements ». Le corps doit inclure la motivation du changement et la comparer avec le comportement antérieur.

Pied de page

Le pied de page doit contenir toutes les informations sur les dernières modifications et constitue également l'endroit idéal pour référencer les problèmes JIRA que ce commit Closes .

Les changements de rupture doivent commencer par le mot BREAKING CHANGE: avec un espace ou deux nouvelles lignes. Le reste du message de validation est ensuite utilisé à cet effet.

Crochets de validation

Dans ce référentiel, des hooks git sont utilisés (configurés avec husky ) pour vérifier le code source "propre".

Vérification du format plus joli

Si les fichiers Typescript ou SCSS sont modifiés et poussés, un hook de validation est déclenché et les fichiers préparés sont formatés avec plus joli. Il effectue le formatage/les modifications, valide et pousse ces modifications, à l'aide de fichiers .

Commutation du message Linting

Vérifie si le message git commit est un message git commit conventionnel, sinon il annulera la validation.

Version et version du projet

Le dernier commit sur la branche release doit définir la version du projet et générer le journal des modifications, cela doit être fait avec npm run release . Cet ensemble correspond à la version du projet , génère le journal des modifications et valide ces modifications . Plus d'informations peuvent être trouvées dans le chapitre : Journal des modifications conventionnel / Commits

Poursuite de l'intégration et du déploiement

Sur ce projet, Travis CI est configuré en tant que lint-, test-, e2e-tests- et build-slave. Si tout a été testé et construit avec succès, Travis CI déploiera la WebApp sur FireBase .