3 ms·

Interesting, I've never worked anywhere where engineers decide when to release changes. That's a product decision, and there is a process of review and approval

• pcl 6y ago
  At Cisco (Webex team), the engineers decide when to release code, and most features are enabled by configs or feature flags independently of the deploys. The engineering team is responsible for the mess caused by a bad deploy, so it's appropriate that those engineers should also choose the timing. Our team typically deploys between 10am and 4ish, local time, since that's when we're at our desks and ready to click through the approvals and monitor the changes as they go through our pipelines. The feature enablement happens through an EFT / beta process, and the final timing of GA enablement is a PM decision. But features are widely used by customers ahead of that time, as part of the rollout process. Our team usually rolls out non-feature changes to services via dynamic configuration switches, so that we can get new bits in place, and then enable new behavior without a redeploy. This also enables us to roll back the dynamic config quickly if something unexpected happens. (We generally don't do this for net new functionality; there's lower risk in adding a new REST endpoint etc. than in changing an existing query's behavior or implementation.)