example_git_flow_QA_and_release_management_checklist.md

The following example code, QA and release management checklist assumes a git branching model like this:

• master branch is protected, and changes least frequently, only when develop is merged into it.
  • develop branch is protected, and changes infrequently, and ideally only when feature and release branches off it are merged into it.
    • variously named release branches, branched off develop, finalized as various feature/fix branches off it are marged into it.
      • (optional, depending on number of developers on the release and need) variously named feature/fix branches off release branches, frequently made and merged into a release branch.

Also, a kanban or similar project management series of columns like the following may help track issues through the process. QA may move failed items back from "QA this" to "coding" to signal programmers that a fix or new feature failed (with detailed notes on the failure mode) :

backlog | up next (or current sprint) | in progress | ready for QA | QA passed | stakeholder approved | closed

• create new release branch off develop; optionally create fix/feature branches off new release branch
• when proposed fixes/features complete, merge all fix/feature branches into release branch (maybe ideally with code review and pull requests)
• if development must move to a next release when proposed fixes/features are complete (but not tested), make new release branch off develop, and merge previous release branch into next release branch. This leaves develop alone but keeps code continuity into next proposed release.
• Code freeze on release candidate branch; no further development on it without QA involvement
• build from release candidate and deploy to QA, stakeholder / volunteer / public test staging, and Apple / Android / other app stores for review/approval
• collate issue descriptions in release and rewrite for public-facing and stakeholder release notes
• QA test in determined scope: full (maximum scope), or essentials (less scope), or critical only (least scope), plus proposed fixes and new features (additional scope that varies per release). See over here (link) for example scopes.
• QA sends all failures back to in progress, programmer proposed fixes move from in progress forward again to ready for QA, and this back-and-forth repeats until everything for the release ends up either in QA passed or is kicked back to in progress (is moved to next release). Items determined ultimately out of scope and which will never be done go straight to closed.
• on QA final approval of release:
  • push the "go" buttons in app stores or wherevere else the final product is published (release)!
  • git tag release branch (name after release)
  • code/resource management (archive) of release resources
  • merge release candidate branch into develop (via pull request if applicable; ideally with code review)
  • if necessary, also merge release candidate branch into next release branch (keep developments in sync)
  • merge develop into master (via pull request if applicable; ideally with code review)
• close release tracking project
• high five