Goals

Catch 95% of prod issues during deployment testing process

A deployment test completed twice by the Operations Workstream during the release process:

A full regression test is done once a week by an Operations Workstream Contributor on Fridays to catch anything that might have snunk in during the week.

Pieces of the manual flow of regression testing is to be eliminated by automated testing via cypress tests.

Operations prioritizes blocking bugs, supporting engineers, and efficiency in the processes already in place over chasing non-blocking bugs for a ‘perfected’ release.

Agreements

Operations, Engineering, and Product Workstreams, as well as any other specific release stakeholders agree to the following:

All pushes to production follow the release cadence outlined in the release process or are considered emergency changes that would follow the Prod Issues protocol and processes

Any blocking bugs found during the testing of a develop branch are to be tested opposite current production, recreated, and clearly posted in a new thread in #operations-publicchat to be addressed and resolved before a LGTM is given from the Operations Leader on the release.

The triage process will be followed for all non-blocking bug reports

The Operations Lead for a release will follow the responsibilities listed in the release process and will track all details of their release in the Releases Table

Blocking bugs/Functionality tests

This is a list of key features and expected behaviors of the ShapeShift product suite that if broken, are considered blockers to the release: