Ask HN: How do you push your code to your server?

[_g2lm]

Most people write code on localhost then push to servers after testing. How do you do the second part? I've heard of git push, rsync, ftp, etc. I also know some people who just edit the code directly on the server over ssh.

What do you do? And how often do you push out code-- every few lines, or every hundred lines, etc.?

[hamiltonkibbe]

This is just for my personal site (wordpress), and probably isn't relevant for a webapp at scale:

a fabric script + git/Github

I develop on localhost and use a python script (with fabric) to manage deployment with git

>>fab git_commit: changes all the Wordpress url references in the database from localhost to production url, dumps the database, uses sed to replace localhost with production url in a few other files, and runs git commit.

>>fab deploy: pushes local repo to private Github repository, runs git pull on production server, and updates the production database from the database dump in the repo.

[alexandern]

I have built a custom tool Dploy(screenshots here[1]) for exactly this purpose. It's built using ASP.NET MVC.

To deploy a project (or a deployable, as I call it), you push to BitBucket. The latest changeset is then pulled using a post-commit hook.

Then it's just a matter of opening the Web GUI and press a button to do the actual deploy.

All manual steps are effectively removed. If the build/copy/whatever fails, nothing will break (hopefully).

Functions currently supported: * Real time output (using web sockets)

* Support for console applications, web applications (using IIS) and NServiceBus endpoints

* Run arbitrary post-deploy commands

* Show diffs so you know what you deploy

* Email notifications

* and more..

Planned functions: * Running tests

* Git support (currently Mercurial only)

* Arbitrary Windows services

* Special post-deploy commands depending on if you deploy up or down

* Deploy to other machines (local only at the moment)

It's not open source at the moment but i would love to do that. If someone want to help out, hit me up (nyquist [.] alexander @ gmail [.] com).

[1] http://imgur.com/a/tIRr9

[stevekemp]

I've got a few different approaches for deployments.

For static sites, which are built from templates, or by hand, I just deploy via rsync. This is nice and efficient, and is carried out over SSH which allows me to be secure in-transit and avoid having to enter passwords.

For dynamic applications I've tended to write simple recipes via fabric (http://fabfile.org/) which allows me to bundle up the local state of a repository, transfer it over SSH, and run a few commands.

For some things in the middle I use git pushes to different environments, but I'm trying to move away from that and into more scripted deployment via ansible, fabric, slaughter, etc.

[27182818284]

git push staging master

or git push staging dev:master

>just edit the code directly on the server over ssh.

Don't do that unless it is a horrible bug fix. Like a security vuln you need to push immediately. Take the extra time to put it into dev or whatever and then push / upload it to wherever.

>I've heard of git push, rsync, ftp, etc.

This really depends on what I'm doing. Obviously if I'm pushing to Heroku it is Git, but I also help out some local folk with the website about their farm fresh eggs. For the latter it is just FTP, because nothing more is necessary. (I I guess I do use a static site generator similar to http://jekyllrb.com/)

[motyar]

I use Dropbox to push data to my VPS.

BTW I edit code remotely using Vim + Netrw + SSH tunnel http://motyar.github.io/14/vim_fast_remote.html

[shrikrishna]

Here's what I do

1. Develop locally, use Github/Bitbucket for version control

2. ssh into my vps and use git pull

3. Configure things like api secrets (ssh + vim)

If there is a bug that needs to be fixed, go back to local, fix, push, ssh, pull, deploy

[update] Formatting changes

[Spoom → shrikrishna]

We did something like this earlier on (we use Chef for deployment now). I just wanted to point out that if you're using git pull as your deployment tool, make sure you use git pull --ff-only. You don't want to have to figure out merge conflicts in production.

[krapp]

>I also know some people who just edit the code directly on the server over ssh.

I've edited js directly over sftp sometimes. But it was for a service for which the choices were ftp or a web editor which I refuse to use, on test pages. For Wordpress I have local installs of each site and a development install just for plugins, and I usually keep a backup on bitbucket and a test deploy on pagodabox.

>And how often do you push out code-- every few lines, or every hundred lines, etc.?

Not very often. Some of my personal projects can go months without so much as a look.

[cheeyoonlee]

We do everything on localhost with git. We keep a master (server) and develop (ready to push to master) and with develop we branch it off into different major features i.e. feature/login, etc. Once the branches are ready we push them into develop to bug test and when all's good we push the changes to master. We only push to master when the code has been somewhat significantly changed like adding a new feature or fixing bugs.

[sgy]

You can try Secure Copy (scp) from your terminal. It uses ssh for data transfer and provides the same authentication and same level of security as ssh. Also, it transfers files and directories.

Examples at : http://www.computerhope.com/unix/scp.htm

[read]

A similar question: how soon can you see results from a code change?

Another question: does pushing code interrupt the app?

I'm slightly embarrassed to say I hack on the server when I can, because it lets me have feedback quickly after a fix. It also helps stay focused; coding in a sandbox is boring by comparison.

[nareshv]

say /var/www/html is where the code is served from.

Active symlink is maintained to the proper build which comes from (say hudson/jenkins)

Say the current symlink is /var/www/html -> build.v5

Below commands illustrate the sequence of the deployment via ssh for the next build number 6 (which can even be a no-op build)

tar jcf build.v6.tar.bz2 build.v6

scp build.v6.tar.bz2 prod-server:/var/www/

ssh prod-server 'VER=6; cd /var/www && tar jxf build.v$VER.tar.bz2 && ln -sf html build.v$VER && sudo service httpd reload'

Similar logic is followed with the help of git/etc. Idea is to 'keep versions' of your code. so that if things get messed up you can rollback quickly. Most people don't think of rollback, until it bites them really bad !

[dk8996]

Github for source control. Codeship for testing, packaging, push to S3. Bash for pulling the releases from S3 and deploying them. This is all done with a help of SBT. I haven't been able to find something that replaces Bash but open to ideas.

[2810]

I wrote a small laravel deployment app where it will run a set of instruction when triggered. So from my localhost I will run git push origin -- master. Once pushed, I run php artisan command:deploy [app-name] [branch].

[payapp]

I use Apple Script to produce builds for Android, iOS, and Server war files. For server SCP works really well and simple - I have intentionally not added in the Apple Script to transmit server builds.

[kiksy]

Code local, merge working branch into dev/master on github, deploy to dev/prod using deployhq.

I make a deploy whenever I deem a feature to be complete, rather than just basing it on line count.

[Spoom]

We use Chef scripts for both app deployment and server spin-up. Fairly heavy investment at the start to build all the recipes, but it pays off big time in time saved later on.

[st3fan]

I sftp a .war file to a remote deployment directory. Old app gets undeployed, new app gets deployed.

[andretti1977]

If possible git pull or svn updat on server, otherwise ftp or scp or war deployment via browser

[alexkus]

Capistrano

[redspark → alexkus]

Surprised this isn't a more popular response.

Vagrant/Puppet for local development

* this way every developer has an identical dev environment.

Git for code versioning - Github/Bitbucket for repo hosting

* each feature has a branch, then we use pull requests for review/merging into staging branch.

* when features are LGTM and tested, pull request to merge into production branch

Capistrano with multi-staging to deploy to staging and production servers

* every developer can deploy to staging

* only a few developers can deploy to production.