Test Cases

• Dedicated process
  • Manual + automatic
• Steps
• Measurable results
• Involve team early (to follow on what's expected from the project)

Strategy

• "Human" feedback (e.g.: "why is this so complicated", "is something different", "why is the page so slow"

Benefits

• Error-prone (human)
• Slooooooow to execute
• Requires dedicated people
• Will slow down releases

Releases

• Semver
  • Good to label releases
  • Variable per product? (e.g.: website a nr. is enough? For a module, it's more important)
• Changelog

Strategy

• Document fixes and improvements
• Estimate

Benefits

• Requires coordination
• Slower releases (but they do exist)

- https://softwareengineering.stackexchange.com/questions/366725/semantic-versions-versions-for-web-applications

- https://www.parkersoftware.com/blog/the-three-software-release-types-and-what-they-mean-for-users/

Git Workflow

• Consistent flow (GitFlow, etc.)
• Predictable branching model and CI configuration
• Prevents errors
  • updating wrong branch/settings 

Strategy

• Logged project
• Easy to check for errors
• Predictable structure (where to branch from, branch to where, what settings are there)
• Easy to coordinate
• Useful routines (CI)

Benefits

• Requires standards
• Requires discipline (resist the urge to update stuff directly)
• Branch cleaning (automatic?)

Conventional Commits

• Commit patterns
• Can be used for automatic changelogs
• Are checkable
• There's helper tools (commitizen)

Strategy

• Consultable project history (e.g.: figure out what broke something)

Benefits

• Easy to mess without enforcing procedures

CI/DevOps

• Automate quality routines

Strategy

• Enforces practices (even for those without a local setup)
  • Unit Testing
  • End to end testing
  • Contract testing
  • Commit structure

Benefits

• Requirements
  • Command line knowledge 
  • Privileged accesses (repository, server)