crossBILLy

crossBILLy – Michael Alekseew

@alekseew/ crossBILLy

Dieses Repository enthält eine Web- und Cross-Plattform-App (Web PWA, Windows, Mac OS X, iOS und Android) zur einfachen Rechnungserstellung. Dieses Projekt soll helfen, Kundendaten zu pflegen, die Rechnungsstellung/Abrechnung durchzuführen, ...

Folgende Frameworks, Plattformen, Bibliotheken, Plugins, Konzepte, Architekturen, Techniken usw. werden verwendet oder ausprobiert:

• Verzweigungsmodell der Quellcodeverwaltung: GitFlow
• Frontend-WebApp-Plattform/Framework: Angular
• Plattformübergreifendes Build-Tool/Framework: Ionischer Kondensator oder Cordova und Elektron
• Entwicklungssprache: Typescript / ( JavaScript )
• WebApp-UI-Bibliothek: Angular Material
• WebApp-UI-Bibliothek „Verhalten“: Angular CDK
• Codeformatierung: Hübscher
• Versionierung, automatisches Changelog (Releases): Standard-Version
• Commit-Message-Tool: Commitizen
• Git-Hooks-Tool: Husky
• Animationen: Lottie & Lottie-Web
• Hosting und mehr...: FireBase
• Kontinuierliche Integration (CI) / Tests & Builds: Travis
• Abhängigkeitsüberwachung: Greenkeeper
• wird fortgesetzt...

Voraussetzungen

Für dieses Projekt müssen zuvor die folgenden Abhängigkeiten installiert werden:

• Node.js
• NPM

Abhängigkeiten

Um alle benötigten Abhängigkeiten zu installieren, führen Sie einfach Folgendes aus:

npm install

Dadurch wird auch die Git-Commit-Nachrichtenvorlage eingerichtet (und das WIP-Paket so eingestellt, dass es commitizen verwendet).

GitFlow

Bitte verwenden Sie das GitFlow- Verzweigungsmodell und die Standardnamen für die Zweige von SourceTree in diesem Projekt. Weitere Informationen finden Sie hier:

• GitFlow
• SourceTree + GitFlow

Namenskonvention für Zweignamen und Präfixe (Standardeinstellung in SourceTree):

• Produktionszweig: Meister
• Entwicklungszweig: entwickeln
• Feature-Branch-Präfix: feature/
• Präfix des Release-Zweigs: release/
• Hotfix-Zweigpräfix: hotfix/
• Kein Versions-Tag-Präfix (die Tag-Namen lauten beispielsweise v0.1.0)

Konventionelles Changelog/Commits

In diesem Projekt werden (Angular-)konventionelle Commits verwendet. Angular Commit Message Guidelines werden verwendet.

Sie werden verwendet, um das Änderungsprotokoll automatisch mit dem npm-Paket standard-version zu generieren. Führen Sie dazu einfach npm run release aus. Dadurch wird folgende Aufgabe erledigt:

• Aktualisieren Sie die Projektversion
• Generieren/aktualisieren Sie CHANGELOG.md
• Übernehmen Sie diese Änderungen (bereit zum Übertragen auf die Fernbedienung)
• Generieren Sie ein Git-Tag

Sie können npm run commit verwenden, um einen Assistenten zu erhalten, der Ihnen hilft, die richtigen Commit-Nachrichten zu schreiben (dies geschieht mit commitizen ).

Außerdem werden die Commit-Nachrichten mit commitlint auf ihre Richtigkeit überprüft (wenn Sie es wirklich überspringen müssen, können Sie die Githooks umgehen, aber Sie sollten es nicht normal tun).

Sie können eine Git-Commit-Nachrichtenvorlage mit npm run prepare-git-commit-template generieren. Dies wird auch während der npm-Installation durchgeführt.

Commit-Nachrichtenformat

Der Header (bestehend aus type , Scope und subject ) sollte nicht länger als 72 Zeichen sein.

 type(scope?): subject

body?

footer?

Typ

Muss einer der folgenden sein:

• feat : Eine neue Funktion
• fix : Eine Fehlerbehebung
• Dokumente : Nur die Dokumentation ändert sich
• Stil : Änderungen, die sich nicht auf die Bedeutung des Codes auswirken (Leerzeichen, Formatierung, fehlende Semikolons usw.)
• Refactor : Eine Codeänderung, die weder einen Fehler behebt noch eine Funktion hinzufügt
• perf : Eine Codeänderung, die die Leistung verbessert
• Test : Fehlende Tests hinzufügen oder vorhandene Tests korrigieren
• Build : Änderungen, die sich auf das Build-System, die CI-Konfiguration oder externe Abhängigkeiten auswirken (Beispielbereiche: gulp, broccoli, npm)
• ci : Änderungen an unseren CI-Konfigurationsdateien und Skripten (Beispielbereiche: Travis, Circle, BrowserStack, SauceLabs)
• chore : Andere Änderungen, die weder src noch test verändern
• revert : Setzt einen vorherigen Commit zurück

Umfang

Der Bereich kann ein beliebiger Bereich sein, der den Ort der Commit-Änderung angibt. Ich verwende folgende Konventionen (Beispiele):

• alle : Änderungen für das gesamte Projekt (allgemeine Projektfreigabe, ...)
• root : Änderungen im Stammverzeichnis (Ordner) des Projekts
• sein : Änderungen im Backend-Teil des Projekts
• zB : Änderungen im Frontend-Teil (Webapp) des Projekts

Thema

Der Betreff enthält eine kurze Beschreibung der Änderung:

• Verwenden Sie den Imperativ im Präsens: „verändern“, nicht „verändert“ oder „verändert“
• Schreiben Sie den ersten Buchstaben nicht groß
• kein Punkt (.) am Ende

Körper

Verwenden Sie wie im Subjekt den Imperativ im Präsens: „verändern“, nicht „verändert“ oder „verändert“. Der Körper sollte die Motivation für die Veränderung einbeziehen und diese dem bisherigen Verhalten gegenüberstellen.

Fußzeile

Die Fußzeile sollte alle Informationen zu wichtigen Änderungen enthalten und ist auch der Ort, an dem auf JIRA-Probleme verwiesen wird, die dieser Commit schließt .

Breaking Changes sollten mit dem Wort BREAKING CHANGE: mit einem Leerzeichen oder zwei Zeilenumbrüchen. Dafür wird dann der Rest der Commit-Nachricht verwendet.

Commit-Hooks

In diesem Repo werden Git-Hooks verwendet (Einrichtung mit husky ), um nach „sauberem“ Quellcode zu suchen.

Schönere Formatprüfung

Wenn Typescript- oder SCSS-Dateien geändert und gepusht werden, wird ein Commit-Hook ausgelöst und die bereitgestellten Dateien werden mit Prettier formatiert. Es führt die Formatierung/Änderungen und Commits durch und überträgt diese Änderungen mit Hilfe von ziemlich schnell .

Commit-Nachrichten-Linting

Überprüft, ob die Git-Commit-Nachricht eine herkömmliche Git-Commit-Nachricht ist, andernfalls wird der Commit abgebrochen.

Projektversion und -freigabe

Der letzte Commit im Release-Zweig sollte die Projektversion festlegen und das Changelog generieren. Dies sollte mit npm run release erfolgen. Dieser legt die Projektversion fest , generiert das Änderungsprotokoll und übernimmt diese Änderungen . Weitere Informationen finden Sie im Kapitel: Konventionelles Changelog / Commits

Fortsetzung der Integration und Bereitstellung

Bei diesem Projekt ist Travis CI als Lint-, Test-, E2E-Tests- und Build-Slave eingerichtet. Wenn alles erfolgreich getestet und erstellt wurde, stellt Travis CI die WebApp auf FireBase bereit.