
Ask HN: How do you push your code to your server? - brandonhsiao
Most people write code on localhost then push to servers after testing. How do you do the second part? I&#x27;ve heard of git push, rsync, ftp, etc. I also know some people who just edit the code directly on the server over ssh.<p>What do you do? And how often do you push out code-- every few lines, or every hundred lines, etc.?
======
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](http://imgur.com/a/tIRr9)

------
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.

------
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/](http://jekyllrb.com/))

------
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.

------
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.

------
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.

------
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 !

------
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](http://www.computerhope.com/unix/scp.htm)

------
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](http://motyar.github.io/14/vim_fast_remote.html)

------
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/](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.

------
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.

------
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.

------
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].

------
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.

------
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.

------
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

------
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
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_.

------
alexkus
Capistrano

~~~
redspark
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.

