How Yipit deploys from Github with multiple private repos (opens in new tab)

Not if you structure your repo correctly.

> not clear what code has and has not been deployed

You can have your production machines deploy from specific branches. In other words, master is the development branch, some-version-branch is the production branch. You can also do it vice versa. You can use tags. Lots of solutions.

> code is not explicitly validated (automatically, manually, on a build/test lab)

If you use the structure above, you wouldn't commit to a production branch unless you did that. Another solution is to force validation/testing using hooks before allowing a commit to a production branch on your development machine.

> and it isn't clear who triggered the release.

Not sure what you mean here ... every commit is recorded, so you always know who did what.

I know where you are coming from with compiled languages. A big reason for creating this flow was for working with repositories that are not our primary code repository. We have several internal tools and forks that don't have a complex deployment process. We wanted the simplicity of being able to push to master and knowing that it will be out in ~30 minutes. Our primary code base is rolled out with Fabric instead of Chef (for now) but Fabric will still need to execute a pull from Github at some point during the rollout.

How is that more secure? They're both running the same code base. That means they have the same vulnerabilities. Both also need to be public facing to deploy code.

Not a bad idea since it would make easier to pull changes outside of the automation without needing to specify the GIT_SSH variable.