I used to create prepress (print manufacturing) software for Mac (old and new) & Windows. Multi platform, multi executables, multi language, multi target builds. It'd pull all the resource bundles (L10N/I18N), recreate the the screen shots, rebuild the PDFs (manuals, marcom). The QA box farm would rerun all the regressions (combo of VirtualPC and VMware boxes) on multiple versions of multiple OSes (eg Japanese Windows) with all the necessary drivers (eg security dongles, which totally sucked). We'd end up with CD images and downloadable zips on our private website for VARs and high end customers.

Seemed to work pretty good.

I used to do a lot of electronic medical records stuff. My team (of 4 core devs) supported five regional exchanges (the first to market), 80 hospitals plus all their partners, pharma scripts, labs (internal and external), feeds to the govt (eg CDC, SSI). Basically 100s of data feeds of every mutant format and protocol imaginable. At the time, all of the data had to be stored on each customer's servers. Meaning we had to deploy and support in situ. Meaning firewalls, reverse SSH, forklifting files into place, whatever was permitted. We did multiple builds per week. Most deploys were push. Some we had to setup as pulls. We implemented auto updates, but never had the QA/Test resources to achieve the necessary confidence, which was a shame.

Seemed to work pretty good.

Sure, today's cloud deploys are complicated in other ways. But the more stuff changes, the more it all looks the same.

PS- Rereading your comment... Maybe consider changing some of the steps from push to pull. I was super inspired by the architecture of postfix (email server). Trying to mimick it simplified a lot of my own efforts.