Peer review Architecture

[FlatBallFlyer]

Please Review:

• Architecture principle, diagrams (and issues).
• 2-stage docker builds
• GitHub Actions templates in this repo
• GitHub Acrions in the mongodb, person-api, and person-ui repositories.
• Use and configuration for GitHub Container Registry
• Review Versioning approach for API & UI
  • Determine if git commit hash the best patch value
  • Requirement - find code based on version reported in /config and /admin
  • Should we have CI create a "release" in the repository?

Please create issues for any recommended changes.

[charlie-r]

Would it make sense to automatically generate a version number in the build system vs reading in /config or /admin (or are there auto-generated version numbers in those places already?)
I think your suggestion for having CI move builds/containers all the way through "release" makes sense. Generally I find that removing the human from the loop on the path to release leads to more reliable software in the long run and less engineering low value work.

[FlatBallFlyer]

The version approach uses a developer maintained semantic Major.Minor, and then the patch level is automatically generated by the Docker Build when the CI runs. It currently uses branch-commit-hash for the patch level. See the template 2-stage builds in the docker-configurations folder. I've considered using the GitHub API to create a "release" and use that info in the patch position, or possibly a date-time stamp. I'm open to other ideas.

I've updated the CICD documentation with this summary.