Trebuchet provides git deploy service restart and git deploy report service that will restart your service with a default batch-size of 10% and report on the status of your service across servers respectively.
There should be a way to restart services in Scap3.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | thcipriani | T119449 Need a way to restart services without deploying via scap | |||
| Resolved | • mmodell | T128892 Move scap3 service restart to it's own stage |
Unlike a normal deploy there is no recourse for deployers that do a restart via Scap3 that fails subsequent checks. If a service restart fails or a service port is unavailable after a restart, there's no clear action for the deployment tooling other than reporting that information.
One way to implement this would be split out service restart from the promote stage of deploy; however, there are services that will not require a restart to begin reading new code (non-repo-authratative hhvm for example) where splitting this step would be tricky to get right with the pooling and depooling of servers (T104352). It might make more sense to have service restart/check code that both the cli-interface deploy --restart (or whatever) and the promote stages can call.
In thinking about this problem a bit more, I think it may be problematic to entirely split promote into promote/restart, mainly for the pooling reasons you mention. However, we could reimplement restart as an "ex" stage much (ala rollback) and delegate to it at the end of promote. That would provide both consistent control over depooling (always wraps the promote stage) but still allow for restart to be invoked directly via -s restart.
Restarting seems more like a scap(2.0) task rather than a deployment stage. The same goes for config diff.