Everything you mentioned seems to be accomplished with a simple "git push". When git (or similar VCS) is involved, the push of a new revision of the codebase should (in my opinion) be what triggers a CI build/deploy. As mentioned in krick's comment, the codebase (specifically the branch that is tracked for releases) is the authoritative place to know what code is running on production.
Otherwise, we have a disconnect between what's in the codebase and what's running on production, and we must ask the question "did the latest code get deployed yet?" or "who is responsible to 'vagrant push' this revision?" - all of which can be avoided by letting the VCS workflow determine all of that.
I love vagrant for what it does best: simplify development environments. I fear that the "push" functionality is treading into unrelated territory. The problem is not what technically happens with a "vagrant push", but rather the idea of "starting deployments" (as you said) from individual developers in their local development context. In my opinion, developers don't initiate deployments; deployments happen passively in response to code changes - assuming it passes any relevant tests/conditions.
Otherwise, we have a disconnect between what's in the codebase and what's running on production, and we must ask the question "did the latest code get deployed yet?" or "who is responsible to 'vagrant push' this revision?" - all of which can be avoided by letting the VCS workflow determine all of that.
I love vagrant for what it does best: simplify development environments. I fear that the "push" functionality is treading into unrelated territory. The problem is not what technically happens with a "vagrant push", but rather the idea of "starting deployments" (as you said) from individual developers in their local development context. In my opinion, developers don't initiate deployments; deployments happen passively in response to code changes - assuming it passes any relevant tests/conditions.