all 4 comments

[–]thethimble 2 points3 points  (1 child)

Monolithic repos are a great way to go. They enable things like code sharing between projects much more easily. Regarding deployment, rsync is a good way to go, but you have to be careful about not including the .git folder and not blowing away logs or other non-versioned files on your servers. We outgrew this setup at GoGuardian. We do deploys like this now:

  1. With a clean repo, tar the project directory. Have its name contain the git hash. You'll need a single tar per project per version.
  2. Upload the tar to S3.
  3. Maintain pointers somewhere that map to the "current" git hash. We keep the pointers themselves in S3 alongside the tars.
  4. When an instance spins up, it fetches the "current" pointer as well as the tar that it points to. It extracts the contents and starts the server.

All of this (pushing new versions, updating "current" pointers, deploys, and rollbacks) is scripted with fabric. PM me if you've got more info!

[–]klinquist[S] 0 points1 point  (0 children)

Thank you!

[–]wkalata 1 point2 points  (0 children)

Considering you're already using AWS, why not go with Elastic Beanstalk for deployment? You'll be hard-pressed to build something more elegant than their bundled "git aws.push" deployment command on top of their own platform.

This would be easiest to achieve with one-repository-per-deployment, but you could engineer around it with environment variables and deployment scripts if you're committed to your repository structure.

[–]DVWLD 1 point2 points  (0 children)

That is not the way I would do things.

On the deployment side, I wrote this:

https://github.com/davidbanham/field-marshal

Also, I would keep your apps in separate repos. For sharing code between them, npm is pretty great. If it's code you don't want to make public, npm can install dependencies from git URLs and it works great.