5 ms·

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 no

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.

crazygringo 14y ago
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?
- latchkey 14y ago
  Over time, you will add features to that script and it'll grow and eventually become 'a more advanced tool'. Everything starts from somewhere.
- gnw 14y ago
  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 https://github.com/bjeanes/ghost to automate this.
  - mnutt 14y ago
    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.
mqzaidi 14y ago
We use a slightly modified version of deploy from visionmedia (https://github.com/visionmedia/deploy 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.
mscdex 14y ago
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 https://gist.github.com/4281277 [2] https://github.com/mscdex/ssh2 https://github.com/mscdex/ssh2

crazygringo 14y ago

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?

latchkey 14y ago
Over time, you will add features to that script and it'll grow and eventually become 'a more advanced tool'. Everything starts from somewhere.
gnw 14y ago
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 https://github.com/bjeanes/ghost to automate this.
- mnutt 14y ago
  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.

mqzaidi 14y ago

We use a slightly modified version of deploy from visionmedia (https://github.com/visionmedia/deploy 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.

mscdex 14y ago

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 https://gist.github.com/4281277 [2] https://github.com/mscdex/ssh2 https://github.com/mscdex/ssh2