Stata batch workers ↔ Kubernetes rolling update: can code changes be picked up without restart?

Goal

Migrate a small Stata‑based analytics service to a new version of its do‑file while keeping the service available to callers.

Constraints & uncertainty

• Stata runs in batch mode (stata -b do file.do) and only reloads the script when the process restarts.
• A network license permits multiple concurrent workers, enabling blue‑green or rolling deployments.
• preserve/restore protect in‑memory data but not open windows or macro state.
• License checkout latency can introduce brief pauses when scaling the worker pool.

Open questions

1. Does a rolling update that replaces the do‑file on disk guarantee that newly started batch workers execute the new code without any in‑flight job seeing a mixed version?

2. What is the measurable license‑checkout delay under typical pool sizes, and can it be bounded to meet a strict zero‑downtime SLA?

3. Are there documented patterns (e.g., sidecar reloader, configmap‑driven script injection) that let the orchestrator signal a clean restart without external downtime?