Multidimensional testing workflow before merge to master

Have you ever had a situation when developer with 100% confidence (works on my local) broken your master branch right before the release. We all were there. I know.

Would it be great to run tests on his changes before they get merged? Would it be nice to actually "test" as site with his changes being applied?

Lately we were improving process of github pull requests by using CI Jenkins to spin up separate environments per pull requests so QA can be done on each pull request before it gets merged.

We will talk about:

• static analysis tools that run as a first step (php code sniffer, css/jslint, security practises)
• build actual site based on the changes of pull request (installation profile vs pulling live database workflow)
• running automated phpunit, simpletest, behat tests
• visual regression testing (comparing screenshots and displaying diffs to spot regressions)
• automated deployments to dev, staging, production environments (cover Acquia environmens as well) once code has been merged
• ensure all the urls are working (no unexpected 404s, infinite redirects)
• test website to see if editors haven't uploaded too big images to the site and they are displayed without resizing

Also we will talk about how do we use vagrant in our process and what tools being shipped with our standard image.