If we want a code review on anything risky, we may push a branch or we may just post the commit in chat for review before we build out. Which is chosen depends on how big or blocking the change may be.
We ask for code reviews all the time, we simply don't mandate them - I think that's the main difference.
> or we may just post the commit in chat for review before we build out.
Isn't that 'after the fact', considering your teamcity polls the gitlab repo a lot, so a commit will trigger a build right after it, and if everything goes well, deploy it too?
So you have to know up front whether a thing is 'risky', but that's a subjective term.
It only deploys to our development/CI environment automatically. Deploying out to the production tier is a button press still.
So yes, it will build to dev, but we're using this in situations where we're very confident the changes are correct already. I'd argue blind pushes are the problem otherwise. If the developer is not very certain: they can open a merge/pull request or just hop on a hangout to do a review.
We ask for code reviews all the time, we simply don't mandate them - I think that's the main difference.