Ask HN: How do you push your code to your server?
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.?
21 comments
[ 5.4 ms ] story [ 60.5 ms ] threador 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/)
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.
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.
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.
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.
BTW I edit code remotely using Vim + Netrw + SSH tunnel http://motyar.github.io/14/vim_fast_remote.html
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
Examples at : http://www.computerhope.com/unix/scp.htm
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 !
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
I make a deploy whenever I deem a feature to be complete, rather than just basing it on line count.
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.