

Ask HN: Which tool(s) do you use to install/upgrade your app on production? - NeoCoder82

Ask HN: Which tool(s) do you use to install/upgrade your app on production?
======
jermy
We use puppet for configuration that varies between systems, but otherwise
bundle our software as debian packages so just need to run 'apt-get dist-
upgrade' per machine. Separate private repositories for
testing/staging/production sets of the packages.

~~~
ankhmoop
What do you use to produce dpkgs? In addition to the cumbersome standard
tools, I'm only aware of jpkg (<http://code.google.com/p/jpkg-library/>) for
Java.

I've found the dpkg method to be very effective. You can sign the packages,
mirror the repositories, and set up servers to automatically upgrade some/all
of the packages via cron jobs.

Packages can be automatically generated by your continual integration system,
which also has the nice effect of creating a fully-trusted and centralized
deployment path, making it difficult to sneak in uncommitted changes and non-
managed files, etc.

The packages themselves support complex dependencies, start/stop scripts, etc,
and dpkg/apt-get themselves have been ported to non-Linux platforms.

Personally, I'd still like a more comprehensive centrally managed solution
based around the packaging model (ie, each server runs a management agent that
can install/remove/update packages, etc).

~~~
sunkencity
I use capistrano and in some cases i use debian packages. As the debian tools
don't work on OS X. I've made a debian package tool called apt_fu that can run
on any unix system. It's at github:

<http://github.com/sunkencity/apt_fu/tree/master>

it's really a quick hack, but it get's the job done.

~~~
ankhmoop
You can install apt-get and dpkg on Mac OS X via MacPorts (but apt_fu looks
quite a bit nicer than using the dpkg tools).

------
cera
capistrano.

You should spend time understanding all of the given capistrano recipes before
you should start building any of your own since many things are already done
for you.

I wasn't able to do this without staring at the capistrano code for a
significant amount of time, but it was worth the effort IMHO.

------
jerryji
Mercurial (distributed revision control system) --

    
    
      $ hg pull ; hg update

~~~
ErrantX
we too use this. we have a waterfall build tool called Merx (custom in house,
hopefully soon OS) that makes nightly builds from out dev and stable hg
repositories.

Thhe builds themselves go into a package repository and on a machine we just
run hg pull packages/<tool>; hg merx <machine name>; hg update;

(hg merx pulls customised machine configuration files from the repository or
defaults if non-existant).

It takes a bit of initial setup but then works well for ongoing deployment (we
add 10-15 commodity servers to our pool each week = easy to do now - dd the
debian image and run those three commands. sorted).

------
Jasber
Lately I've been using Fabric: <http://docs.fabfile.org/>

So far it meets my needs well. The only issue I had was getting my SSH key
working, but I was eventually able to iron that out.

------
zacharypinter
I recently setup a Rails app to deploy to EC2 with chef and chef-deploy
(<http://github.com/ezmobius/chef-deploy>).

I think chef has a lot of potential. However, I found the learning curve
rather high. If you end up using it, you'll definitely want to use a VM with
snapshots.

------
zacharydanger
I use Git in with a detached working copy a la <http://toroid.org/ams/git-
website-howto> but with a little more flair for schema updates and things like
that.

So my deployment looks like:

    
    
      git push live

------
bretthoerner
Fabric: <http://docs.fabfile.org/>

~~~
cuerty
I use fabric too, it's easy because most of the developments done here are in
Python and writing a "deployment script" in the same language makes sense. The
only problem I get with this is the "socket closed" error from time to time.

------
gamache
We don't use source control on our production machines (which I think is
crap), so I use an rsync script from my dev machine. Many people just scp the
files over every time they make a change. (There was once a tendency by a few
folks to directly edit files on production, without ever checking these
changes in to SVN; thank god this has decreased over time.) Work is also too
cheap to buy SQL migration tools for everyone who needs them, so database
changes are applied by hand. Not awesome.

------
__david__

        darcs push
    

which sends patches to the test repo and

    
    
        ssh remote darcs --repo=live pull ../test
    

which is in a makefile so we can just do:

    
    
        make release
    

Let me add here that darcs' inherent cherry picking abilities are a wonderful
match for web development. Being able to fast track changes to the live site
with no hassle is heavenly.

------
lpgauth
Deploy? We use Capistrano which is ok for simple setups, but it gets hairy if
you have multiple configurations (staging, production).

~~~
croby
capistrano-ext multistage

<http://weblog.jamisbuck.org/2007/7/23/capistrano-multistage>

------
petercooper

      git push && ssh wherever 'cd /wherever; git pull; [touch or restart something]'

~~~
jrockway
I tend to "git pull --rebase", so that local config changes "stay on top" and
don't become a merge commit.

In general, I recommend against "git pull" unless you are intentionally trying
to merge something. (Fast-forwards are a special case of merging.)

~~~
petercooper
Good point, although I maintain different environment configurations separate
from the code base (or .gitignore anything that doesn't fall into that).

------
dedalus
I wrote my own custom python program that pretty much acts like a distributed
shell to automate pushes (svn/git,etc)

Its pretty close to this:
<http://www.netfort.gr.jp/~dancer/software/dsh.html.en>

------
sowbug
Puppet with RPMs in yum repositories. Python scripts push individual RPMs to
the development repository, then to staging, and finally to production.

Also a few custom tweaks to restart the Puppet daemons when they die, which
they do frequently.

------
oakmac
I use git on development machines and have an rsync script to push updates to
the server.

