Two projects I have been following that I like are Salt and Ansible.<p><a href="http://saltstack.com/community.html" rel="nofollow">http://saltstack.com/community.html</a><p><a href="http://www.ansibleworks.com/" rel="nofollow">http://www.ansibleworks.com/</a>
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...)<p>Before 2 days ago I used Heroku for everything.<p>PS. Rails.
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.<p>Definitely worth a look
I have been using <a href="http://beanstalkapp.com/" rel="nofollow">http://beanstalkapp.com/</a> 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.)<p>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.<p>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.<p>But for beginners Beanstalk (<a href="http://beanstalkapp.com" rel="nofollow">http://beanstalkapp.com</a>) 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.<p>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.
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.<p>Unfortunately at work we're still on svn...
Mostly Cap and Git, but Ansible (<a href="http://www.ansibleworks.com/" rel="nofollow">http://www.ansibleworks.com/</a>) caught my eye recently for experimentation. Looks very promising.
Currently Chef. It's great for getting a machine in order, but it's proven to be a real bear for actually managing deployment of server processes.<p>We're working on a deployment manager based on Substack's fleet.<p><a href="https://github.com/substack/fleet" rel="nofollow">https://github.com/substack/fleet</a>
<a href="https://github.com/PinionTech/rear-admiral" rel="nofollow">https://github.com/PinionTech/rear-admiral</a>
1. Atlassian Bamboo for polling my git repository for changes<p>2. Apache ANT for the build script<p>3. Then back out to a production/tarball git repo<p>4. Every load balanced server image has a cron job to poll the production git for changes<p>This way all I( or my team members) have to do is push to git.<p>Everything else is automated. All servers load balancing will keep themselves up to date.
Infrastructure changes:<p>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.
Chef + Caterer (<a href="https://github.com/tylerflint/caterer" rel="nofollow">https://github.com/tylerflint/caterer</a>)<p>Chef - because it's so easy to write cookbooks<p>Caterer - because the push model is clean, and it has a similar workflow to Vagrant.
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.
Just came across dokku this week
<a href="https://github.com/progrium/dokku" rel="nofollow">https://github.com/progrium/dokku</a><p>Couldn't give it a try yet, but seems rather interesting
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)<p>Shouldn't Heroku be on this?
Is anyone using Octopus for .NET stack deployment? <a href="http://octopusdeploy.com/" rel="nofollow">http://octopusdeploy.com/</a>