| ▲ | packet_mover 4 days ago | |||||||
Thanks for chiming in - super helpful context. I am trying to learn from real deployments as I design Corviont's updater for edge boxes (bandwidth caps, maintenance windows, unreliable WAN, atomic swap + rollback). When you say transit "zones" are small enough to deploy incrementally - what is the actual artifact per zone (roughly what format), and what sizes do you typically see? And when a transit zone dataset changes, how do you roll that out safely - do you restart/reload the backend that serves that zone, or do you bring up a new backend/version and then flip travelmux to point at it? | ||||||||
| ▲ | ikawe 4 days ago | parent [-] | |||||||
Transit routing is provided by OpenTripPlanner, so the deployment artifact is their OTP serialized graph format. So it’s not really incremental with respect to the existing transit zone deployment. I just mean I can redeploy a single transit zone with the latest GTFS without having to touch the other transit zones, tileserver, geocoder, etc. Deployment/rollback is handled by k8s config. | ||||||||
| ||||||||