datacontract-cli 0.9.7__tar.gz → 0.9.8__tar.gz

{datacontract-cli-0.9.7/datacontract_cli.egg-info → datacontract-cli-0.9.8}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: datacontract-cli
-Version: 0.9.7
+Version: 0.9.8
 Summary: Test data contracts
 Author-email: Jochen Christ <jochen.christ@innoq.com>, Stefan Negele <stefan.negele@innoq.com>
 Project-URL: Homepage, https://cli.datacontract.com
@@ -11,7 +11,7 @@ Classifier: Operating System :: OS Independent
 Requires-Python: >=3.10
 Description-Content-Type: text/markdown
 License-File: LICENSE
-Requires-Dist: typer[all]~=0.9.0
+Requires-Dist: typer[all]<0.13,>=0.9
 Requires-Dist: pydantic<2.7.0,>=2.5.3
 Requires-Dist: pyyaml~=6.0.1
 Requires-Dist: requests~=2.31.0
@@ -19,23 +19,27 @@ Requires-Dist: fastapi==0.110.0
 Requires-Dist: fastparquet==2024.2.0
 Requires-Dist: python-multipart==0.0.9
 Requires-Dist: rich~=13.7.0
-Requires-Dist: simple-ddl-parser==1.0.3
-Requires-Dist: soda-core-bigquery~=3.2.1
-Requires-Dist: soda-core-duckdb~=3.2.1
-Requires-Dist: soda-core-postgres~=3.2.1
-Requires-Dist: soda-core-snowflake~=3.2.1
-Requires-Dist: soda-core-spark[databricks]~=3.2.1
-Requires-Dist: soda-core-spark-df~=3.2.1
+Requires-Dist: simple-ddl-parser==1.0.4
+Requires-Dist: soda-core-bigquery<3.4.0,>=3.3.1
+Requires-Dist: soda-core-duckdb<3.4.0,>=3.3.1
+Requires-Dist: soda-core-postgres<3.4.0,>=3.3.1
+Requires-Dist: soda-core-snowflake<3.4.0,>=3.3.1
+Requires-Dist: soda-core-spark[databricks]<3.4.0,>=3.3.1
+Requires-Dist: soda-core-spark-df<3.4.0,>=3.3.1
 Requires-Dist: snowflake-connector-python[pandas]<3.8,>=3.6
-Requires-Dist: duckdb==0.10.0
+Requires-Dist: duckdb==0.10.1
 Requires-Dist: fastjsonschema~=2.19.1
 Requires-Dist: python-dotenv~=1.0.0
-Requires-Dist: s3fs==2024.2.0
+Requires-Dist: s3fs==2024.3.1
 Requires-Dist: rdflib==7.0.0
 Requires-Dist: avro==1.11.3
+Requires-Dist: opentelemetry-exporter-otlp-proto-grpc~=1.16.0
+Requires-Dist: opentelemetry-exporter-otlp-proto-http~=1.16.0
 Provides-Extra: dev
 Requires-Dist: httpx==0.27.0; extra == "dev"
+Requires-Dist: ruff; extra == "dev"
 Requires-Dist: pytest; extra == "dev"
+Requires-Dist: testcontainers<4.0; extra == "dev"
 Requires-Dist: testcontainers-minio; extra == "dev"
 Requires-Dist: testcontainers-postgres; extra == "dev"
 Requires-Dist: testcontainers-kafka; extra == "dev"
@@ -55,6 +59,15 @@ It uses data contract YAML files to lint the data contract, connect to data sour
 
 ![Main features of the Data Contract CLI](datacontractcli.png)
 
+<div align="center">
+  <a href="https://www.youtube.com/watch?v=B1dixhgO2vQ">
+ <img 
+  src="https://img.youtube.com/vi/B1dixhgO2vQ/0.jpg" 
+  alt="Demo of Data Contract CLI" 
+  style="width:100%;">
+  </a>
+</div>
+
 ## Getting started
 
 Let's look at this data contract:
@@ -139,9 +152,6 @@ $ datacontract import --format sql --source my_ddl.sql
 
 # import avro
 $ datacontract import --format avro --source avro_schema.avsc
-
-# import protobuf as model (Coming Soon)
-$ datacontract import --format protobuf --source my_protobuf_file.proto datacontract.yaml
 ```
 
 ## Programmatic (Python)
@@ -155,7 +165,15 @@ if not run.has_passed():
     # Abort pipeline, alert, or take corrective actions...
 ```
 
-## Scenario: Integration with Data Mesh Manager
+## Integrations
+
+
+| Integration       | Option                       | Description                                                                                           |
+|-------------------|------------------------------|-------------------------------------------------------------------------------------------------------|
+| Data Mesh Manager | `--publish`                  | Push full results to the [Data Mesh Manager API](https://api.datamesh-manager.com/swagger/index.html) |
+| OpenTelemetry     | `--publish-to-opentelemetry` | Push result as gauge metrics (logs are planned)                                                       |
+
+### Integration with Data Mesh Manager
 
 If you use [Data Mesh Manager](https://datamesh-manager.com/), you can use the data contract URL and append the `--publish` option to send and display the test results. Set an environment variable for your API key.
 
@@ -165,7 +183,7 @@ $ EXPORT DATAMESH_MANAGER_API_KEY=xxx
 $ datacontract test https://demo.datamesh-manager.com/demo279750347121/datacontracts/4df9d6ee-e55d-4088-9598-b635b2fdcbbc/datacontract.yaml --server production --publish
 ```
 
-## Scenario: Integration with OpenTelemetry
+### Integration with OpenTelemetry
 
 If you use OpenTelemetry, you can use the data contract URL and append the `--publish-to-opentelemetry` option to send the test results to your OLTP-compatible instance, e.g., Prometheus.
 
@@ -184,14 +202,13 @@ The metric name is "datacontract.cli.test.result" and it uses the following enco
 # Fetch current data contract, execute tests on production, and publish result to open telemetry
 $ EXPORT OTEL_SERVICE_NAME=datacontract-cli
 $ EXPORT OTEL_EXPORTER_OTLP_ENDPOINT=https://YOUR_ID.apm.westeurope.azure.elastic-cloud.com:443
-$ EXPORT OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20secret (Optional, when using SaaS Products)
-$ EXPORT OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf (Optional, because it is the default value)
+$ EXPORT OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20secret # Optional, when using SaaS Products
+$ EXPORT OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf # Optional, default is http/protobuf - use value grpc to use the gRPC protocol instead
 # Send to OpenTelemetry
 $ datacontract test https://demo.datamesh-manager.com/demo279750347121/datacontracts/4df9d6ee-e55d-4088-9598-b635b2fdcbbc/datacontract.yaml --server production --publish-to-opentelemetry
 ```
 
 Current limitations:
-- no gRPC support
 - currently, only ConsoleExporter and OTLP Exporter
 - Metrics only, no logs yet (but loosely planned)
 
@@ -482,22 +499,36 @@ datacontract export --format dbt
 
 Available export options:
 
-| Type               | Description                                             | Status |
-|--------------------|---------------------------------------------------------|--------|
-| `jsonschema`       | Export to JSON Schema                                   | ✅      | 
-| `odcs`             | Export to Open Data Contract Standard (ODCS)            | ✅      | 
-| `sodacl`           | Export to SodaCL quality checks in YAML format          | ✅      |
-| `dbt`              | Export to dbt models in YAML format                     | ✅      |
-| `dbt-sources`      | Export to dbt sources in YAML format                    | ✅      |
-| `dbt-staging-sql`  | Export to dbt staging SQL models                        | ✅      |
-| `rdf`              | Export data contract to RDF representation in N3 format | ✅      |
-| `avro`             | Export to AVRO models                                   | ✅      |
-| `protobuf`         | Export to Protobuf                                      | ✅      |
-| `terraform`        | Export to terraform resources                           | ✅      |
-| `sql`              | Export to SQL DDL                                       | ✅      |
-| `sql-query`        | Export to SQL Query                                     | ✅      |
-| `pydantic`         | Export to pydantic models                               | TBD    |
-| Missing something? | Please create an issue on GitHub                        | TBD    |
+| Type                 | Description                                             | Status |
+|----------------------|---------------------------------------------------------|--------|
+| `jsonschema`         | Export to JSON Schema                                   | ✅      | 
+| `odcs`               | Export to Open Data Contract Standard (ODCS)            | ✅      | 
+| `sodacl`             | Export to SodaCL quality checks in YAML format          | ✅      |
+| `dbt`                | Export to dbt models in YAML format                     | ✅      |
+| `dbt-sources`        | Export to dbt sources in YAML format                    | ✅      |
+| `dbt-staging-sql`    | Export to dbt staging SQL models                        | ✅      |
+| `rdf`                | Export data contract to RDF representation in N3 format | ✅      |
+| `avro`               | Export to AVRO models                                   | ✅      |
+| `protobuf`           | Export to Protobuf                                      | ✅      |
+| `terraform`          | Export to terraform resources                           | ✅      |
+| `sql`                | Export to SQL DDL                                       | ✅      |
+| `sql-query`          | Export to SQL Query                                     | ✅      |
+| `great-expectations` | Export to Great Expectations Suites in JSON Format      | ✅      |
+| `bigquery`           | Export to BigQuery Schemas                              | TBD    |
+| `pydantic`           | Export to pydantic models                               | TBD    |
+| `html`               | Export to HTML page                                     | TBD    |
+| Missing something?   | Please create an issue on GitHub                        | TBD    |
+
+#### Great Expectations
+The export function transforms a specified data contract into a comprehensive Great Expectations JSON suite. 
+If the contract includes multiple models, you need to specify the names of the model you wish to export.
+```shell
+datacontract  export datacontract.yaml --format great-expectations --model orders 
+```
+The export creates a list of expectations by utilizing:
+
+- The data from the Model definition with a fixed mapping
+- The expectations provided in the quality field for each model (find here the expectations gallery https://greatexpectations.io/expectations/)
 
 #### RDF
 
@@ -535,13 +566,120 @@ Available import options:
 | Type               | Description                                    | Status  |
 |--------------------|------------------------------------------------|---------|
 | `sql`              | Import from SQL DDL                            | ✅       | 
-| `protobuf`         | Import from Protobuf schemas                   | TBD     |
 | `avro`             | Import from AVRO schemas                       | ✅     |
+| `protobuf`         | Import from Protobuf schemas                   | TBD     |
 | `jsonschema`       | Import from JSON Schemas                       | TBD     |
+| `bigquery`         | Import from BigQuery Schemas                   | TBD     |
 | `dbt`              | Import from dbt models                         | TBD     |
 | `odcs`             | Import from Open Data Contract Standard (ODCS) | TBD     |
 | Missing something? | Please create an issue on GitHub               | TBD     |
 
+## Best Practices
+
+We share best practices in using the Data Contract CLI.
+
+### Data-first Approach
+
+Create a data contract based on the actual data. This is the fastest way to get started and to get feedback from the data consumers.
+
+1. Use an existing physical schema (e.g., SQL DDL) as a starting point to define your logical data model in the contract. Double check right after the import whether the actual data meets the imported logical data model. Just to be sure.
+    ```bash
+    $ datacontract import --format sql ddl.sql
+    $ datacontract test
+    ```
+
+2. Add examples to the `datacontract.yaml`. If you can, use actual data and anonymize. Make sure that the examples match the imported logical data model.
+   ```bash
+   $ datacontract test --examples
+   ```
+
+
+3. Add quality checks and additional type constraints one by one to the contract and make sure the examples and the actual data still adheres to the contract. Check against examples for a very fast feedback loop.
+   ```bash
+   $ datacontract test --examples
+   $ datacontract test
+   ```
+
+4. Make sure that all the best practices for a `datacontract.yaml` are met using the linter. You probably forgot to document some fields and add the terms and conditions.
+   ```bash
+   $ datacontract lint
+   ```
+
+5. Set up a CI pipeline that executes daily and reports the results to the [Data Mesh Manager](https://datamesh-manager.com). Or to some place else. You can even publish to any opentelemetry compatible system.
+   ```bash
+   $ datacontract test --publish https://api.datamesh-manager.com/api/runs
+   ```
+
+### Contract-First
+
+Create a data contract based on the requirements from use cases.
+
+1. Start with a `datacontract.yaml` template.
+   ```bash
+   $ datacontract init
+   ```
+   
+2. Add examples to the `datacontract.yaml`. Do not start with the data model, although you are probably tempted to do that. Examples are the fastest way to get feedback from everybody and not loose someone in the discussion.
+
+3. Create the model based on the examples. Test the model against the examples to double-check whether the model matches the examples.
+    ```bash
+    $ datacontract test --examples
+    ```
+   
+4. Add quality checks and additional type constraints one by one to the contract and make sure the examples and the actual data still adheres to the contract. Check against examples for a very fast feedback loop.
+    ```bash
+    $ datacontract test --examples
+    ```
+
+5. Fill in the terms, descriptions, etc. Make sure you follow all best practices for a `datacontract.yaml` using the linter.
+    ```bash
+    $ datacontract lint
+    ```
+
+6. Set up a CI pipeline that lints and tests the examples so you make sure that any changes later do not decrease the quality of the contract.
+    ```bash
+    $ datacontract lint
+    $ datacontract test --examples
+    ```
+
+7. Use the export function to start building the providing data product as well as the integration into the consuming data products.
+    ```bash
+    # data provider
+    $ datacontract export --format dbt
+    # data consumer
+    $ datacontract export --format dbt-sources
+    $ datacontract export --format dbt-staging-sql
+    ```
+
+### Schema Evolution
+
+#### Non-breaking Changes
+Examples: adding models or fields
+
+- Add the models or fields in the datacontract.yaml
+- Increment the minor version of the datacontract.yaml on any change. Simply edit the datacontract.yaml for this.
+- You need a policy that these changes are non-breaking. That means that one cannot use the star expression in SQL to query a table under contract. Make the consequences known.
+- Fail the build in the Pull Request if a datacontract.yaml accidentially adds a breaking change even despite only a minor version change
+   ```bash
+  $ datacontract breaking datacontract-from-pr.yaml datacontract-from-main.yaml
+  ```
+- Create a changelog of this minor change.
+   ```bash
+  $ datacontract changelog datacontract-from-pr.yaml datacontract-from-main.yaml
+  ```
+#### Breaking Changes
+Examples: Removing or renaming models and fields.
+
+- Remove or rename models and fields in the datacontract.yaml, and any other change that might be part of this new major version of this data contract.
+- Increment the major version of the datacontract.yaml for this and create a new file for the major version. The reason being, that one needs to offer an upgrade path for the data consumers from the old to the new major version.
+- As data consumers need to migrate, try to reduce the frequency of major versions by making multiple breaking changes together if possible.
+- Be aware of the notice period in the data contract as this is the minimum amount of time you have to offer both the old and the new version for a migration path.
+- Do not fear making breaking changes with data contracts. It's okay to do them in this controlled way. Really!
+- Create a changelog of this major change.
+   ```bash
+  $ datacontract changelog datacontract-from-pr.yaml datacontract-from-main.yaml
+  ```
+
 ## Development Setup
 
 Python base interpreter should be 3.11.x (unless working on 3.12 release candidate).
@@ -554,7 +692,8 @@ source venv/bin/activate
 # Install Requirements
 pip install --upgrade pip setuptools wheel
 pip install -e '.[dev]'
-cd tests/
+ruff check --fix
+ruff format --check
 pytest
 ```
 

datacontract-cli-0.9.7/PKG-INFO → datacontract-cli-0.9.8/README.md

@@ -1,45 +1,3 @@
-Metadata-Version: 2.1
-Name: datacontract-cli
-Version: 0.9.7
-Summary: Test data contracts
-Author-email: Jochen Christ <jochen.christ@innoq.com>, Stefan Negele <stefan.negele@innoq.com>
-Project-URL: Homepage, https://cli.datacontract.com
-Project-URL: Issues, https://github.com/datacontract/cli/issues
-Classifier: Programming Language :: Python :: 3
-Classifier: License :: OSI Approved :: MIT License
-Classifier: Operating System :: OS Independent
-Requires-Python: >=3.10
-Description-Content-Type: text/markdown
-License-File: LICENSE
-Requires-Dist: typer[all]~=0.9.0
-Requires-Dist: pydantic<2.7.0,>=2.5.3
-Requires-Dist: pyyaml~=6.0.1
-Requires-Dist: requests~=2.31.0
-Requires-Dist: fastapi==0.110.0
-Requires-Dist: fastparquet==2024.2.0
-Requires-Dist: python-multipart==0.0.9
-Requires-Dist: rich~=13.7.0
-Requires-Dist: simple-ddl-parser==1.0.3
-Requires-Dist: soda-core-bigquery~=3.2.1
-Requires-Dist: soda-core-duckdb~=3.2.1
-Requires-Dist: soda-core-postgres~=3.2.1
-Requires-Dist: soda-core-snowflake~=3.2.1
-Requires-Dist: soda-core-spark[databricks]~=3.2.1
-Requires-Dist: soda-core-spark-df~=3.2.1
-Requires-Dist: snowflake-connector-python[pandas]<3.8,>=3.6
-Requires-Dist: duckdb==0.10.0
-Requires-Dist: fastjsonschema~=2.19.1
-Requires-Dist: python-dotenv~=1.0.0
-Requires-Dist: s3fs==2024.2.0
-Requires-Dist: rdflib==7.0.0
-Requires-Dist: avro==1.11.3
-Provides-Extra: dev
-Requires-Dist: httpx==0.27.0; extra == "dev"
-Requires-Dist: pytest; extra == "dev"
-Requires-Dist: testcontainers-minio; extra == "dev"
-Requires-Dist: testcontainers-postgres; extra == "dev"
-Requires-Dist: testcontainers-kafka; extra == "dev"
-
 # Data Contract CLI
 
 <p>
@@ -55,6 +13,15 @@ It uses data contract YAML files to lint the data contract, connect to data sour
 
 ![Main features of the Data Contract CLI](datacontractcli.png)
 
+<div align="center">
+  <a href="https://www.youtube.com/watch?v=B1dixhgO2vQ">
+ <img 
+  src="https://img.youtube.com/vi/B1dixhgO2vQ/0.jpg" 
+  alt="Demo of Data Contract CLI" 
+  style="width:100%;">
+  </a>
+</div>
+
 ## Getting started
 
 Let's look at this data contract:
@@ -139,9 +106,6 @@ $ datacontract import --format sql --source my_ddl.sql
 
 # import avro
 $ datacontract import --format avro --source avro_schema.avsc
-
-# import protobuf as model (Coming Soon)
-$ datacontract import --format protobuf --source my_protobuf_file.proto datacontract.yaml
 ```
 
 ## Programmatic (Python)
@@ -155,7 +119,15 @@ if not run.has_passed():
     # Abort pipeline, alert, or take corrective actions...
 ```
 
-## Scenario: Integration with Data Mesh Manager
+## Integrations
+
+
+| Integration       | Option                       | Description                                                                                           |
+|-------------------|------------------------------|-------------------------------------------------------------------------------------------------------|
+| Data Mesh Manager | `--publish`                  | Push full results to the [Data Mesh Manager API](https://api.datamesh-manager.com/swagger/index.html) |
+| OpenTelemetry     | `--publish-to-opentelemetry` | Push result as gauge metrics (logs are planned)                                                       |
+
+### Integration with Data Mesh Manager
 
 If you use [Data Mesh Manager](https://datamesh-manager.com/), you can use the data contract URL and append the `--publish` option to send and display the test results. Set an environment variable for your API key.
 
@@ -165,7 +137,7 @@ $ EXPORT DATAMESH_MANAGER_API_KEY=xxx
 $ datacontract test https://demo.datamesh-manager.com/demo279750347121/datacontracts/4df9d6ee-e55d-4088-9598-b635b2fdcbbc/datacontract.yaml --server production --publish
 ```
 
-## Scenario: Integration with OpenTelemetry
+### Integration with OpenTelemetry
 
 If you use OpenTelemetry, you can use the data contract URL and append the `--publish-to-opentelemetry` option to send the test results to your OLTP-compatible instance, e.g., Prometheus.
 
@@ -184,14 +156,13 @@ The metric name is "datacontract.cli.test.result" and it uses the following enco
 # Fetch current data contract, execute tests on production, and publish result to open telemetry
 $ EXPORT OTEL_SERVICE_NAME=datacontract-cli
 $ EXPORT OTEL_EXPORTER_OTLP_ENDPOINT=https://YOUR_ID.apm.westeurope.azure.elastic-cloud.com:443
-$ EXPORT OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20secret (Optional, when using SaaS Products)
-$ EXPORT OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf (Optional, because it is the default value)
+$ EXPORT OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20secret # Optional, when using SaaS Products
+$ EXPORT OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf # Optional, default is http/protobuf - use value grpc to use the gRPC protocol instead
 # Send to OpenTelemetry
 $ datacontract test https://demo.datamesh-manager.com/demo279750347121/datacontracts/4df9d6ee-e55d-4088-9598-b635b2fdcbbc/datacontract.yaml --server production --publish-to-opentelemetry
 ```
 
 Current limitations:
-- no gRPC support
 - currently, only ConsoleExporter and OTLP Exporter
 - Metrics only, no logs yet (but loosely planned)
 
@@ -482,22 +453,36 @@ datacontract export --format dbt
 
 Available export options:
 
-| Type               | Description                                             | Status |
-|--------------------|---------------------------------------------------------|--------|
-| `jsonschema`       | Export to JSON Schema                                   | ✅      | 
-| `odcs`             | Export to Open Data Contract Standard (ODCS)            | ✅      | 
-| `sodacl`           | Export to SodaCL quality checks in YAML format          | ✅      |
-| `dbt`              | Export to dbt models in YAML format                     | ✅      |
-| `dbt-sources`      | Export to dbt sources in YAML format                    | ✅      |
-| `dbt-staging-sql`  | Export to dbt staging SQL models                        | ✅      |
-| `rdf`              | Export data contract to RDF representation in N3 format | ✅      |
-| `avro`             | Export to AVRO models                                   | ✅      |
-| `protobuf`         | Export to Protobuf                                      | ✅      |
-| `terraform`        | Export to terraform resources                           | ✅      |
-| `sql`              | Export to SQL DDL                                       | ✅      |
-| `sql-query`        | Export to SQL Query                                     | ✅      |
-| `pydantic`         | Export to pydantic models                               | TBD    |
-| Missing something? | Please create an issue on GitHub                        | TBD    |
+| Type                 | Description                                             | Status |
+|----------------------|---------------------------------------------------------|--------|
+| `jsonschema`         | Export to JSON Schema                                   | ✅      | 
+| `odcs`               | Export to Open Data Contract Standard (ODCS)            | ✅      | 
+| `sodacl`             | Export to SodaCL quality checks in YAML format          | ✅      |
+| `dbt`                | Export to dbt models in YAML format                     | ✅      |
+| `dbt-sources`        | Export to dbt sources in YAML format                    | ✅      |
+| `dbt-staging-sql`    | Export to dbt staging SQL models                        | ✅      |
+| `rdf`                | Export data contract to RDF representation in N3 format | ✅      |
+| `avro`               | Export to AVRO models                                   | ✅      |
+| `protobuf`           | Export to Protobuf                                      | ✅      |
+| `terraform`          | Export to terraform resources                           | ✅      |
+| `sql`                | Export to SQL DDL                                       | ✅      |
+| `sql-query`          | Export to SQL Query                                     | ✅      |
+| `great-expectations` | Export to Great Expectations Suites in JSON Format      | ✅      |
+| `bigquery`           | Export to BigQuery Schemas                              | TBD    |
+| `pydantic`           | Export to pydantic models                               | TBD    |
+| `html`               | Export to HTML page                                     | TBD    |
+| Missing something?   | Please create an issue on GitHub                        | TBD    |
+
+#### Great Expectations
+The export function transforms a specified data contract into a comprehensive Great Expectations JSON suite. 
+If the contract includes multiple models, you need to specify the names of the model you wish to export.
+```shell
+datacontract  export datacontract.yaml --format great-expectations --model orders 
+```
+The export creates a list of expectations by utilizing:
+
+- The data from the Model definition with a fixed mapping
+- The expectations provided in the quality field for each model (find here the expectations gallery https://greatexpectations.io/expectations/)
 
 #### RDF
 
@@ -535,13 +520,120 @@ Available import options:
 | Type               | Description                                    | Status  |
 |--------------------|------------------------------------------------|---------|
 | `sql`              | Import from SQL DDL                            | ✅       | 
-| `protobuf`         | Import from Protobuf schemas                   | TBD     |
 | `avro`             | Import from AVRO schemas                       | ✅     |
+| `protobuf`         | Import from Protobuf schemas                   | TBD     |
 | `jsonschema`       | Import from JSON Schemas                       | TBD     |
+| `bigquery`         | Import from BigQuery Schemas                   | TBD     |
 | `dbt`              | Import from dbt models                         | TBD     |
 | `odcs`             | Import from Open Data Contract Standard (ODCS) | TBD     |
 | Missing something? | Please create an issue on GitHub               | TBD     |
 
+## Best Practices
+
+We share best practices in using the Data Contract CLI.
+
+### Data-first Approach
+
+Create a data contract based on the actual data. This is the fastest way to get started and to get feedback from the data consumers.
+
+1. Use an existing physical schema (e.g., SQL DDL) as a starting point to define your logical data model in the contract. Double check right after the import whether the actual data meets the imported logical data model. Just to be sure.
+    ```bash
+    $ datacontract import --format sql ddl.sql
+    $ datacontract test
+    ```
+
+2. Add examples to the `datacontract.yaml`. If you can, use actual data and anonymize. Make sure that the examples match the imported logical data model.
+   ```bash
+   $ datacontract test --examples
+   ```
+
+
+3. Add quality checks and additional type constraints one by one to the contract and make sure the examples and the actual data still adheres to the contract. Check against examples for a very fast feedback loop.
+   ```bash
+   $ datacontract test --examples
+   $ datacontract test
+   ```
+
+4. Make sure that all the best practices for a `datacontract.yaml` are met using the linter. You probably forgot to document some fields and add the terms and conditions.
+   ```bash
+   $ datacontract lint
+   ```
+
+5. Set up a CI pipeline that executes daily and reports the results to the [Data Mesh Manager](https://datamesh-manager.com). Or to some place else. You can even publish to any opentelemetry compatible system.
+   ```bash
+   $ datacontract test --publish https://api.datamesh-manager.com/api/runs
+   ```
+
+### Contract-First
+
+Create a data contract based on the requirements from use cases.
+
+1. Start with a `datacontract.yaml` template.
+   ```bash
+   $ datacontract init
+   ```
+   
+2. Add examples to the `datacontract.yaml`. Do not start with the data model, although you are probably tempted to do that. Examples are the fastest way to get feedback from everybody and not loose someone in the discussion.
+
+3. Create the model based on the examples. Test the model against the examples to double-check whether the model matches the examples.
+    ```bash
+    $ datacontract test --examples
+    ```
+   
+4. Add quality checks and additional type constraints one by one to the contract and make sure the examples and the actual data still adheres to the contract. Check against examples for a very fast feedback loop.
+    ```bash
+    $ datacontract test --examples
+    ```
+
+5. Fill in the terms, descriptions, etc. Make sure you follow all best practices for a `datacontract.yaml` using the linter.
+    ```bash
+    $ datacontract lint
+    ```
+
+6. Set up a CI pipeline that lints and tests the examples so you make sure that any changes later do not decrease the quality of the contract.
+    ```bash
+    $ datacontract lint
+    $ datacontract test --examples
+    ```
+
+7. Use the export function to start building the providing data product as well as the integration into the consuming data products.
+    ```bash
+    # data provider
+    $ datacontract export --format dbt
+    # data consumer
+    $ datacontract export --format dbt-sources
+    $ datacontract export --format dbt-staging-sql
+    ```
+
+### Schema Evolution
+
+#### Non-breaking Changes
+Examples: adding models or fields
+
+- Add the models or fields in the datacontract.yaml
+- Increment the minor version of the datacontract.yaml on any change. Simply edit the datacontract.yaml for this.
+- You need a policy that these changes are non-breaking. That means that one cannot use the star expression in SQL to query a table under contract. Make the consequences known.
+- Fail the build in the Pull Request if a datacontract.yaml accidentially adds a breaking change even despite only a minor version change
+   ```bash
+  $ datacontract breaking datacontract-from-pr.yaml datacontract-from-main.yaml
+  ```
+- Create a changelog of this minor change.
+   ```bash
+  $ datacontract changelog datacontract-from-pr.yaml datacontract-from-main.yaml
+  ```
+#### Breaking Changes
+Examples: Removing or renaming models and fields.
+
+- Remove or rename models and fields in the datacontract.yaml, and any other change that might be part of this new major version of this data contract.
+- Increment the major version of the datacontract.yaml for this and create a new file for the major version. The reason being, that one needs to offer an upgrade path for the data consumers from the old to the new major version.
+- As data consumers need to migrate, try to reduce the frequency of major versions by making multiple breaking changes together if possible.
+- Be aware of the notice period in the data contract as this is the minimum amount of time you have to offer both the old and the new version for a migration path.
+- Do not fear making breaking changes with data contracts. It's okay to do them in this controlled way. Really!
+- Create a changelog of this major change.
+   ```bash
+  $ datacontract changelog datacontract-from-pr.yaml datacontract-from-main.yaml
+  ```
+
 ## Development Setup
 
 Python base interpreter should be 3.11.x (unless working on 3.12 release candidate).
@@ -554,7 +646,8 @@ source venv/bin/activate
 # Install Requirements
 pip install --upgrade pip setuptools wheel
 pip install -e '.[dev]'
-cd tests/
+ruff check --fix
+ruff format --check
 pytest
 ```