crossBILLy - Michael Alekseew

@alekseew/crossBILLy

This repository contains a Web- and Cross-Platform-App (Web PWA, Windows, Mac OS X, iOS and Android) for easy bill generation. This project should help to maintain customer data, do the invoicing / billing, ...

Used or tryout frameworks, platforms, libraries, plugins, concepts, architectures, techniques, ... are following:

• Source Control Branching-Model: GitFlow
• Frontend WebApp Platform / Framework: Angular
• Cross Platform Build Tool / Framework: Ionic Capacitor or Cordova and Electron
• Development Language: Typescript / (JavaScript)
• WebApp UI Library: Angular Material
• WebApp UI "Behaviour" Library: Angular CDK
• Code-Formatting: Prettier
• Versioning, automatic Changelog (releases): Standard-Version
• Commit Message Tool: Commitizen
• Git-Hooks Tool: Husky
• Animations: Lottie & Lottie-Web
• Hosting and more... : FireBase
• Continous Integration (CI) / Tests & Builds: Travis
• Dependency Monitoring: Greenkeeper
• will be continued ...

Prerequisites

This project requires the following dependencies to be installed beforehand:

• Node.js
• NPM

Dependencies

To install all needed dependencies just run:

npm install

This also setup's up the git commit message template (and set the wip package to use commitizen).

GitFlow

Please use the GitFlow branching model and the default names for the branches of SourceTree in this project, more information's can be found here:

• GitFlow
• SourceTree + GitFlow

Branch names and prefixs naming convention (default setting in SourceTree):

• Production branch: master
• Development branch: develop
• Feature branch prefix: feature/
• Release branch prefix: release/
• Hotfix branch prefix: hotfix/
• No Version tag prefix (the Tag names will be for example v0.1.0)

Conventional Changelog / Commits

In this project (angular) conventional commits Angular Commit Message Guidelines are used.

They will be used to auto generate the changelog with the npm package standard-version, to do this just run npm run release. This will do following task:

• Update the project version
• Generate / update the CHANGELOG.md
• Commit this changes (ready to push to remote)
• Generate a git tag

You can use npm run commit to get a wizard that helps you to write the correct commit messages (this is done with commitizen).

Also the commit messages will be checked that they are correct with commitlint (if you really need to skip it, you can bypass the githooks, but you should not do it normally).

You can generate a git commit message template with npm run prepare-git-commit-template, this will also be done during npm install.

Commit Message Format

The header (consist of type, scope and subject) should not be longer than 72 characters.

type(scope?): subject

body?

footer?

Type

Must be one of the following:

• feat: A new feature
• fix: A bug fix
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• refactor: A code change that neither fixes a bug nor adds a feature
• perf: A code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system, CI configuration or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit

Scope

The scope could be anything specifying place of the commit change. I am using following conventions (examples):

• all: changes for the whole project (general project release, ...)
• root: changes in the root (folder) of the project
• be: changes in the backend part of the project
• fe: changes in the frontend part (webapp) of the project

Subject

The subject contains succinct description of the change:

• use the imperative, present tense: "change" not "changed" nor "changes"
• don't capitalize first letter
• no dot (.) at the end

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

Footer

The footer should contain any information about Breaking Changes and is also the place to reference JIRA issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Commit Hooks

In this repo git hooks are used (setup with husky) to check for "clean" source code.

Prettier Format Check

If Typescript or SCSS files are changed and pushed a commit hook is triggered and the staged files are formatted with prettier. It does the formating / changes and commits and pushes this changes, with the help of pretty-quick.

Commit Message Linting

Checks if the git commit message is a conventional git commit message, otherwise it will cancel the commit.

Project Version & Release

The last commit on the release branch should set the project version and generate the Changelog, this should be done with npm run release. This set's the project verison, generates the changelog and commits this changes. More information's can be found under the chapter: Conventional Changelog / Commits

Continues Integration & Deployment

On this project Travis CI is setup as lint-, test-, e2e-tests- and build-slave. If everything was tested and build successfully Travis CI will deploy the WebApp to FireBase.