[npsimons]

I would argue that a dev environment that is identical to prod, no exceptions, is too constraining. As the OP points out, having root access in the VM to go willy nilly and try out new tools is a must for developers.

I'm kind of surprised they didn't have Jenkins setup from the start; I'm also a bit taken aback that they don't use automated code reviews before accepting patches to their "deploy" branch. Even for a small project, it's not that hard to setup Jenkins+Gerrit to reject patches that break tests (or have to pass whatever other hurdles you want).

[JPaulEtsy]

We only really have one branch "master". We encourage the engineers to push small changes, behind config flags if necessary, all the time so there is never any huge merge conflicts, etc. This also means you don't push your code to master until you are up in our push queue.

We've also had Jenkins set up for a long time now, we just used LXC to drastically improve our performance and scalability.

Here is an old blog post explaining some of how it all works: http://codeascraft.com/2011/04/20/divide-and-concur/

[xiongchiamiov]

When do you do code review?

[JPaulEtsy]

We use a review script that creates a temporary branch in github and sends an email to everyone you specify to review it. We then kill that branch when the review is over. Any time you push code, you run our test suite on your changes then create a review. Since these are encouraged to be small and behind config flags to not affect all our users immediately, it happens quite often. Once feedback is taken from the review you enter our push queue yourself and push it out yourself. If the code is possibly dangerous, we recommend those pushes wait from Friday night to Monday morning for safety's sake.