The reason that we should discuss this is that users ask for support of staging environments. We have to be able to explain to CEs how we are going to support it. Or at least have a prescriptive approach on how our features help with this use case. We may already have variables, but is that enough to support all the use cases we know around staging envs?
Assumption:
We need to ensure that every dataset has it's own contract file as an entry point
This will require some form of reuse & delta's to tweak the contract verification in a test environment (see #2169 )
Alternative: Use the same file for both the production as well as the staging dataset.
This requires the use of variables as the staging dataset may be in another database or schema or have a different dataset name
This may require conditional checks as row counts may be different in testing env
As a producer,
I want to run the use the same contract YAML file to verify data in a test environment as in the production environment
As a producer, I want to skip certain checks in test environment or in production environment
Idea: The contract could include test table values like sample data and a Soda tool could create the test table and insert the data.
The reason that we should discuss this is that users ask for support of staging environments. We have to be able to explain to CEs how we are going to support it. Or at least have a prescriptive approach on how our features help with this use case. We may already have variables, but is that enough to support all the use cases we know around staging envs?
Assumption:
Alternative: Use the same file for both the production as well as the staging dataset.
As a producer, I want to run the use the same contract YAML file to verify data in a test environment as in the production environment
As a producer, I want to skip certain checks in test environment or in production environment
Idea: The contract could include test table values like sample data and a Soda tool could create the test table and insert the data.