Note: This process was established specifically to meet the needs of the DU project. It's recommended to adjust process according to the unique needs of a team.
All Code Reviews
Ping people over slack when you request them to review a PR and when you are done reviewing a PR
Check GitHub regularly to keep an eye on notifications and review requests
Following long PR discussions from slack/zoom, reflect decisions in Github PR comments
Offer solutions and give actionable feedback
Be clear and explicit in comments; don't make people guess what the reviewer wanted
Personal styling is fine as long as it is within reasonable bounds
Allow for personal coding style, but highlight actual issues
Minimize PR size, try and keep PRs to a single idea/story/action
Danger Zone: If there is a lot of back and forth in an PR hop on a zoom call and have a discussion. If an agreement can't be reached post in #truss-kbase-engineering and ask for outside opinions.
Design and Product Manager Review for FE/UI PRs
All FE/UI changes must meet the provided spec
All PR descriptions must include screen shots of the UI changes
Accessibility of UI changes has been properly addressed
Changes will be deployed to the narrative-refactor environment for the designers and PMs to review
If changes are requested during review, developers will make changes and push to narrative-refactor environment for another round of design review. Instructions for deploy to narrative refactor are here.
Once a designer and product manager has approved the changes, the PR can be merged into develop (as well as getting developer PR approval)
Ensure tests can be run automatically
Test PRs when you review them (not just see that the tests pass in CI)
Add documentation for tests that don't run automatically and/or on how to do manual testing
As a general rule test coverage should increase, but be aware of exceptions
Be open to suggestions and new practices
Put an emphasis on knowledge sharing
Share in progress work (draft PRs, in progress demos)
Share ideas:
Investigations to new tools, techniques and approaches
When you’ve tried something new
Pairing
Find the best ways to work together
ci.kbase.us - An initial testing environment, used for all things for continuous integration tests. All services typically get deployed there first with the newest versions. Most new things get iterated on there, uses the develop branch.
next.kbase.us - ideally the next stop for services after CI. Intended to be a final testing before final deployment, uses latest branch.
appdev.kbase.us - this has (typically) all of its services up to date with the production environment and is intended for developing new Apps. It has a different Workspace service, so the data is different, but all the apps are available here. Uses latest branch.
narrative-dev.kbase.us - A place for testing UI and Narrative releases or feature branches. All the services here are in sync with production EXCEPT for the UI pieces - narrative and kbase-ui
https://kbaseincubator.github.io/service_status/ - service status indicator: makes a simple call to most core services and returns green if they’re up and happy. The “Fake Service” that’s still in there was really just a test to make sure it shows errors properly.
Internal Training Narratives (Gavin can help grant access)
Platform demos (go along with training narratives)
Service Blueprints (search for Upload or Batch Analysis)
KBase and Jupyter (workshop talk by Bill Riehl in June 2019)