I've actually spent the last 14 hours learning to deploy to ec2 using rubber. It's definitely powerful, and the railscast helps, but I haven't found much in the way of help for doing anything beyond deploying basic apps (for example, working on setting up resque workers right now...)
I use capistrano for deployment, I mainly like it because I can set up a VPS on any service and have it clone the repo from git, config is almost identical between applications depending on the complexities of each and it can be heavily modified for the clients needs as well.
I have been using http://beanstalkapp.com/ to do automated deployments. Basically it is Github + some nicer deployment features and a corporate repo focus. (Private by default, easy to add / remove / manage account access when adding or removing employees.)
I have experimented with EC2 Beanstalk and AWS OpsWorks. Both are horrible, and I do not recommend them. The documentation is incredibly obscure, with gaping holes for even basic use cases and I found the deployments themselves to be slow to complete, and unreliable, frequently having issues that were extremely hard to diagnose because of hard to access logs and cryptic error messages.
Git is by far the best deployment system in my opinion, especially if you can automate the code to get each server instance to automatically pull when needed.
But for beginners Beanstalk (http://beanstalkapp.com) is the absolute best. It is dead simple to set up a Git repo on the service, and then Beanstalk's servers will automatically deploy via SFTP to servers (or even directly to Amazon S3 for static content, even invalidating CloudFront caches), and you instantly have a secure deployment mechanism out of the box with no fiddling required.
With Node.js code if you are running your server through Forever you can easily configure it to watch the code directory for changes and restart the server when needed. End to end setup is extremely quick, and it is incredibly reliable.
I don't agree that git is best for deployment and that beanstalk is focused on beginners - git deployment actually for beginners and beanstalk becomes much more handy when you have more than 1 server and 1 developer. Also, not in all languages "git pull" is enough, sometimes you need to run custom commands after that to run external (to git) tools.
Github is pretty key for getting my code in front of the largest amount of users - and their private repo's keep the code that makes it to the app store versioned and accessed between all of my different workstations. Not coming from a CS background, I love their product - so naturally I've moved my own coding habits to using git for personal projects.
I guess I meant that GitHub totally changed my creative and coding process to using git and being comfortable with its tooling. I'm fooling around with basic Heroku/RoR stuff now, so that's what I'm mainly using git for deployment purposes.
If it helps, I'm an iOS developer, so git isn't realy an option for deployment.
Edit: I guess if I put a different perspective on it, I deploy my open source tools through GitHub and a good commit system. GitHub is pivotal for getting those tools in front of the largest amount of programmers as possible.
That's quite nice, but your weakness is that a single-point of failure can delay your deployment, without you noticing it early enough. Or do you have solution for that?
We stage all changes on a 'develop' branch and run the same exact build process(thanks to bamboo) and deploy to the staging server.
If QA passes, then we just merge the changes to master, push and deploy to production servers.
Bamboo has a nice variety of test suites you can run too.
I really like that git(via bitbucket) and bamboo notify hipchat of any build failures/updates so we can respond immediately if something serious actually goes wrong.
1. Stash pushes git change notification to bamboo
2. Bamboo checkout git and run cucumber tests on ec2
3. Green tests means puppet changes are pushed to puppet master under staging env
4. Manual build step to push to prod env
5. All affected infra will pickup puppet changes on next run
If I'm just showing off work to clients and pushing things to a staging/dev server, a lot of the time I'll use grunt-rsync or grunt-sftp to push everything up at the end of my `$ grunt produce` task. For site deployments, I prefer Capistrano since it's dead simple.
Has anybody looked into using torrents with git? I've heard a few larger companies use it for fast code deployments across 100's/1000's of servers. I'd be interested in more information on how they do this.
I just started using EC2 BeanStalk. It's been surprisingly painful...the system makes sense, but some of the config details are obscure...(using Rails 3.2 and mysql)
Server ops isn't my thing...and while I've set up EC2 machines before for specific apps and services, I'm trying to build a workflow for deploying as flexibly as I could with Heroku. I looked at Rubber for a brief moment and it felt like too much...so I gave Beanstalk a try.
Beanstalk has components that I can figure out on my own and the command line tools are easy enough...I'm currently stuck on figuring out when the hell it decides to set the DB user and password, despite what I've explicitly set it...so I know what's going wrong, but the whole settings part is much more annoying than it was on Heroku (even without trying to do anything too complicated). But EC2 has the full suite of services I need so I'll stick with it for now. I expect that once I'm comfortable with BeanStalk, it won't be hard to just migrate to old fashioned EC2 and capistrano.
BeanStalk's support for Rails is relatively recent so the lack of questions on StackOverflow is probably why I'm struggling
That's a version control system. OP is talking about a deployment system. Difference is that the deployment system does something with your final code (from your your git/svn/hg/cvs/mnt etc.).
That's what a deployment system is for. It should do 1, 2 and optionally even 3 for you. You should probably look into "landscape" a canonical project.
SaltStack (http://saltstack.com/community.html) and Ansible (http://ansible.cc) would be your two closest options. Of the two, I prefer Ansible for its simplicity and the fact that it can be extended in any language, but it's worth noting that that simplicity currently comes at a cost of power compared to Chef. (E.g., Chef has a concept of "ensure this service is present," and that works on all supported operating systems, whereas Ansible has different modules for different supervisors.)
http://saltstack.com/community.html
http://www.ansibleworks.com/