Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce the turn-around time for testing apps with production like data. #660

Open
ksatchit opened this issue Sep 26, 2022 · 0 comments
Open

Comments

@ksatchit
Copy link

Is this a BUG REPORT or FEATURE REQUEST?

Choose one: BUG REPORT or FEATURE REQUEST

Note:

This issue was originally created on openebs/litmus, when the project mainly hosted e2e tests for the OpenEBS project (functional and chaos related). Since then, litmuschaos has evolved into a pure fault/chaos injection framework. While it can be leveraged to implement e2e tests for cloud-native projects, currently, it is by itself context-agnostic. As a member of both the Litmus and OpenEBS projects, felt that the scope of this issue differs/exceeds that of a pure chaos experiment. Hence transferring this to openebs/e2e-tests from litmuschaos/litmus.

Ref: litmuschaos/litmus#51

Felix is a DevOps admin who is responsible for maintaining Staging Databases for a large enterprise corporation with 400+ developers working on 200+ applications. The Staging database contains a pruned (for user information) and is constantly updated with production data. When developers make some data schema changes, they would like to test them out on the Staging setup with real data before pushing the changes for Review.

  • The staging database PV, PVC and the associated application are created in a separate namespace called “staging”. Only Felix has access to this namespace. He creates snapshots of the production database volume. Along with creating the snapshots, he appends some information into the snapshots that will be helpful for developers like the: like the version of the applications that are running in the staging database when this snapshot was taken.
  • Each developer has their own namespace. For example Simon, runs his development application in “dev-simon-app” namespace.
  • The cluster admin authorize Simon to access (read/get) the snapshots from the staging setup.
  • Simon gets the list of snapshots that are available. Picks up the snapshot or snapshots that are best suited for testing his application.
  • Simon creates a PVC / PV with the select snapshot and launches his applications with modified changes on it.
  • Simon then runs the integration tests on his application which is now accessing production like data - which helps him to identify issues with different types of data and running at scale.
  • After completing the tests, Simon deletes the application and the associated cloned volumes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant