Developer workflow¶
This workflow keeps dpone changes small, reviewable, and production-safe.
1. Start from the contract¶
Before writing runtime code, define or update the user-facing contract:
- Manifest shape.
- CLI behavior.
- Connector capability flags.
- State, schema evolution, quality, and reconciliation behavior.
- Documentation and examples.
2. Add tests first¶
Use a targeted failing test before changing implementation code.
Recommended sequence:
Then implement the smallest change that passes the test.
3. Keep optional imports lazy¶
Connector SDKs must not be imported during import dpone or dpone --help unless the connector is actually executed.
Add optional import tests when introducing a new extra.
4. Update documentation with the code¶
Every public connector or strategy change should update:
- Connector docs.
- Source/sink guide when applicable.
- Load strategy docs.
- Type mapping matrix if schemas are affected.
- Integration-test runbooks.
5. Run the focused gate¶
For broader changes, run the default regression gate from Testing.
6. Produce artifacts for large changes¶
Benchmarks, live certification, and wide-table compatibility checks should create Markdown artifacts in test_artifacts/.
7. Prepare a pull request¶
A good pull request includes:
- Problem and solution summary.
- User-facing behavior changes.
- Test evidence.
- Documentation links.
- Known limitations or follow-up work.