Hacker News Reader

Comment by simontabor | Hacker News Reader

As said in the post, Capistrano is a good option but we found we much preferred deliver, it was easier to setup and meant we didn't need ruby dependencies on node.js apps.

We also used to SSH into our servers and do everything manually. Crazy times.

View on HN

Genuine question (since I'm doing the same with AWS right now) -- I wrote a script which makes an API call to Amazon to find the name of each of my instances, then SSH's into them automatically to do the equivalent of a git clone or update.

Seems to work so far -- any reason why I might want to be using a more advanced tool instead?

Over time, you will add features to that script and it'll grow and eventually become 'a more advanced tool'. Everything starts from somewhere.

If it works for you for now then no real need to change it. A proper deployment tool usually makes it easier to deploy apps of different types and languages using a consistent set of tools.

What I do when working with SSH'ing to AWS instances is to give them a readable name (like nginx-1, nginx-2) tag, and then place those names as hostnames in my /etc/hosts, so I can then just run ssh nginx-1. I use a script around https://github.com/bjeanes/ghost to automate this.

The script looks nice, though if you don't want to have to use sudo to update /etc/hosts you can also just add entries in ~/.ssh/config. Downsides are that it only works for ssh-based activities.

We use a slightly modified version of deploy from visionmedia (https://github.com/visionmedia/deploy). Shell script, and works very well for us.

Of course, when doing releases that affect the database schema, we still have to login to the servers.

I generally use a node script (sometimes a CLI script like [1]) with the ssh2 module [2] for most deployment tasks.

[1] https://gist.github.com/4281277 [2] https://github.com/mscdex/ssh2

Reply on news.ycombinator.com