I've always been opposing push-to-deploy, unless you actually have per-branch, ephemeral test environments, and take the required care to set up your data fixtu

I've always been opposing push-to-deploy, unless you actually have per-branch, ephemeral test environments, and take the required care to set up your data fixtures - which is a major technical challenge on any non-trivial project. The trick is to keep the deployment code simple and stupid, while making the process transparent and dependable for the team. For production environments, rather than thinking in terms of pushing a commit, you want to reframe the problem as promoting a version from a staging environment - preferably subject to approval from QA and/or project owner. ChatOps is great for that, and it doesn't have to be painfully complicated, or full of hacky Hubot code - you can get huge ROI from a simple script[1] that posts a message at the start&end of a deployment, which includes a version string (autogenerated from a git tag[2]), environment, maybe your login/host name ("$(id -un)@$(hostname)"). CI can build the artifacts, then your job is just "./deploy prod v3.14", which is also easily delegated. [1]: def slack_post(data): req = urllib.request.Request( "https://hooks.slack.com/services/xxx/xxx/xxx", headers={"content-type": "application/json"}, data=json.dumps(data).encode("utf8"), method="POST", ) res = urllib.request.urlopen(req) assert res.getcode() in range(200, 300) return res [2]: #!/bin/sh set -eu slugify() { sed -E -e 's/[^A-Za-z0-9]/-/g' -e 's/-+/-/g' -e 's/(^-|-$)//g' } git_tag=$(git describe --tags --dirty --always) git_branch=$(git rev-parse --abbrev-ref HEAD | slugify) case "${git_branch}" in master|HEAD) echo "${git_tag}"; ;; *) echo "${git_tag}-${git_branch}"; ;; esac