/!\ This is a living document and will most likely change throughout the time /!\
(/) Prime directive:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they know at the time, their skills and abilities, the resources available, and the situation at hand.
(/) I suggest we use this template for all pull requests:
#### What is the relevant ticket?
#### What’s this PR do?
##### Add
##### Change
##### Remove
#### Where should the reviewer start?
#### How should this be manually tested?
#### Risk involved?
#### Screenshots (if appropriate):
#### Does the documentation or dependencies need an update?
Note: Not all of these fields are relevant for all of the PRs of course, but you get the idea.
(/) I suggest we use these and ONLY these types of branches, always accompanied by the Jira ticket numbers and short description, no whitespace anywhere and lowercase only – e.g.:
feature/JIRA-1-adding-cronjob
release/JIRA-2-adding-massive-role
bugfix/JIRA-3-removing-bug
hotfix/JIRA-4-removing-nasty-bug
(/) OPTIONAL STEP: Commits should ideally be squashed into one to make the Git history nice and clean and Git message contain clear messages of the change. This is how you squash:
1. Put the to-be-squashed commits on a feature branch (if they aren't already)
2. Check out the target branch ('master')
3. git merge --squash <working branch name>
4. git commit
(/) Follow the code review best practices: https://google.github.io/eng-practices/
(/) When PR was approved, whoever approved it will immediately MERGE it and DELETE the branch.
(/) In the Ansible playbooks, we all should use the same format (this is easily configurable in VSCode (Ctrl+,) and other IDEs):
Indentation: indent using 2 spaces (not tabs!).
Final newline: always insert a final new line at the end of the file when saving it (good POSIX practice when diff or git diff is involved).
Trim final newlines: trim all new lines after the final new line.
Trim trailing whitespaces: trim all trailing whitespaces so it does not confuse git diff.
(/) Follow YAML best practices: https://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html
(/) Follow Ansible playbooks best practices: https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html
(/) Update the documentation when necessary – this is README.md file in the root of repositories.
(/) Read and understand how to write good commit messages: https://github.com/RomuloOliveira/commit-messages-guide
(/) Follow the Semantic Versioning guide https://semver.org/ when tagging the product
(/) Always keep the CHANGELOG.md along with your product code, use this guide https://keepachangelog.com
(/) Always have a license: https://choosealicense.com/
(/) We believe in the A-S-S triangle:
AVAILABILTY (or INNOVATION)
/ \
/ \
/ \
/ \
SIMPLICITY /_________\ SECURITY
- if you have very secure product, it won't be simple nor available
- if you have very simple product, it won't be secure nor available
- if you have extremely available product, it won't be simple nor secure