M1- Engineering Fundamentals Checklist - scheduled for 2/9

brandynbrown commented 3 years ago

Tech Lead's Engineering Fundamentals Checklist

This checklist helps to ensure that our projects meet our Engineering Fundamentals.

[x] The main branch is locked.
[x] Merges are done through PRs.
[x] PRs reference related work items.
[x] Commit history is consistent and commit messages are informative (what, why).
[x] Secrets are not part of the commit history or made public. (see Credential scanning)
[x] Public repositories follow the OSS guidelines, see Required files in default branch for public repositories.

More details on Source Control

More details on Unit Testing

[x] Project runs CI with automated build and test on each PR.
[x] Project uses CD to manage deployments to a replica environment before PRs are merged.
[x] Main branch is always shippable.

[x] Access control.
[x] Separation of concerns. (@ryancrawcour ?)
[x] Robust treatment of secrets. (@ryancrawcour ?)
[x] Encryption for data in transit (and if necessary at rest) and password hashing. (Should be handled by Kafka)

[x] Significant business and functional events are tracked and related metrics collected.
[x] Application faults and errors are logged.
[ ] Health of the system is monitored.
[ ] The client and server side observability data can be differentiated.
[x] Logging configuration can be modified without code changes (eg: verbose mode).
[ ] Incoming tracing context is propagated to allow for production issue debugging purposes.
[x] GDPR compliance is ensured regarding PII (Personally Identifiable Information).

[x] Process Lead (fixed/rotating) to run standup daily.
[x] Agile process clearly defined within team.
[x] Tech Lead (+ PO/Others) have responsibility for backlog management and refinement.
[x] Working agreement between members of team and customer.

[x] Process for conducting design reviews is included in the Working Agreement
[ ] Design reviews for each major component of the solution are carried out and documented, including alternatives.
[ ] Stories and/or PRs link to the design document.
[ ] Each user story includes a task for design review by default, which is assigned or removed during sprint planning.
[ ] Project advisors are invited to design reviews or asked to give feedback to the design decisions captured in documentation.
[ ] Discover all the reviews that the customer's processes require and plan for them.

[x] Clear agreement in the team as to function of code reviews.
[ ] Code review checklist or established process.
[x] A minimum number of reviewers (usually 2) for a PR merge is enforced by policy.
[x] Linters/Code Analyzers, unit tests and successful builds for PR merges are set up.
[x] Process to enforce a quick review turnaround.

More details on Code Reviews

[x] Set time for retrospectives each week/at the end of each sprint.
[x] 1-3 proposed experiments to be tried each week/sprint to improve the process.
[x] Experiments have owners and are added to project backlog.
[x] Longer retrospective for Milestones and project completion.

More details on Retrospectives

brandynbrown commented 3 years ago

add plugin for code coverage analysis
@ryancrawcour for design review, we didn't do any formal ones except for the testing plan (done today), did you do any with PG?
@ryancrawcour observability section needs some love, team felt that this was largely NA for our project.

ryancrawcour commented 3 years ago

Not much needed in terms of design review as a lot of the design is dictated to us by either Kafka Connect, or Cosmos DB. We did do some design discussions with the PG where it made sense.
Agree that observability is mostly NA for this project, besides the logging (which is in place