Versioning, Deployement, Realeasing

[catyphram]

Think about feasible ways to automatically create tags, releases and release notes for the application on Github. Optimally a full continuous delivery pipeline should be set up.

[catyphram]

Technologies that will be used:

• https://travis-ci.org/ as the fundamental CI platform
• https://github.com/conventional-changelog/conventional-changelog, https://github.com/commitizen/cz-cli and https://github.com/marionebl/commitlint for auto formatting and checking of commit messages, as well as changelog generation
• https://github.com/semantic-release/semantic-release for versioning and releasing

A task branching model according to https://guides.github.com/introduction/flow/ will be configured for further development. Also task ids and keywords should be added to commit messages and pull requests to link issues. See https://help.github.com/articles/closing-issues-using-keywords/ for the options.

The application will not be deployed.

A guide for most of the setup can be found here:
https://medium.com/@schalkneethling/automate-package-releases-with-semantic-release-and-commitizen-d7d4c337f04f

[catyphram]

• Travis has been set up to Lint and Unit Test the client and to Lint (via go vet), Unit and Integrate Test the API.
• The master branch has been restricted to only allow pushes via PRs.
• A badge was added to the README to display the build status.

What remains to do:

• Add Contribution section to README explaining the workflow: Linter, Tests, Commit Style, CI, PRs and also later Releasing.
• Have a look at https://github.com/alecthomas/gometalinter as an alternative to go vet.
• Configure commitlint, commitizen and semantic-release as described in the second post.

[catyphram]

For now gometalinter will not be integrated due to problems with Go modules support:
alecthomas/gometalinter#562
alecthomas/gometalinter#564

Usage of the gometalinter or other linters should be revisited at some point in the future, though.

[catyphram]

Semantic Release won't be integrated as this app is not going to be released on npm or Github and is meant to be installed locally.
Since every PR results in one squashed commit, the commit id would be linked with exactly one tag and release and would serve no benefit. The resulting Changelog, too, would replicate the git history.