How to handle complex deployments where branching is not enough?

[geoHeil]

Currently, dagster branch deployments do not allow the execution of sensors or freshness policies.
This means - branch deployments are great - for unit testing the assets in isolation.
Unit testing the interaction of the freshness policies will improve soon #22811

However, sensors - and to some extent the real experience of how the policies interact with each other and the world- are still missing.

How do you solve this challenge?

Do you use a git main branch for a prod deploy, feature branches to test these in isolation and an additional staging branch that deploys to a separate dagster (full) deployment target to test sensors, asset interaction and freshness policies?

[zyd14]

We do github releases for prod deployment, pushes to main get deployed to dev. Sensors and schedules and that stuff mostly get tested in dev. We have an additional staging deployment for running automated full-scale end to end test pipelines as part of the release CI process. We don't really test sensors in staging as staging is mostly just set up for automated integration tests during release process.

[geoHeil]

Why did you decide for this structure? To be more safe? I.e. no automatic deploy? Or in order to better test the sensors?

[geoHeil]

Do you think that with the new upcoming and their better testability #22811 there will be less need for such a (more complex) setup?