Ask HN: how do you stage/push your code?
I was wondering if you could share some best practices for staging and pushing code. Thank you.
11 comments
We use capifony, a Symfony-tailored version of Capistrano.
Because our workflow utilized git flow, we do the majority of our work in feature branches, submit PRs, and then merge those to develop when TravisCI says it passes.
Once on develop, we "cap staging deploy" and run any final tests using Testacular, Selenium, or just by hand.
Most of the time, though, all we do is eyeball the code changes on develop, confirm tests pass in TravisCI, and do a release on master and then "cap production deploy".
Database migrations are handled automatically via Doctrine with each deployment with rollback support.
Sessions are pooled, and there haven't been any issues between releases. NewRelic is our primary indicator for a successful release.
Using this method, we deploy 6+ times a day, and haven't had the the time to automate it all yet :)
Because our workflow utilized git flow, we do the majority of our work in feature branches, submit PRs, and then merge those to develop when TravisCI says it passes.
Once on develop, we "cap staging deploy" and run any final tests using Testacular, Selenium, or just by hand.
Most of the time, though, all we do is eyeball the code changes on develop, confirm tests pass in TravisCI, and do a release on master and then "cap production deploy".
Database migrations are handled automatically via Doctrine with each deployment with rollback support.
Sessions are pooled, and there haven't been any issues between releases. NewRelic is our primary indicator for a successful release.
Using this method, we deploy 6+ times a day, and haven't had the the time to automate it all yet :)
At work, we have different workflows from rsync and ssh into the machine, running a build script to git pull.
For my pet project, I work with git push to the production server. Works pretty well with git post-recieve hook and phing (ant for php) targets to update dependencies (through composer) and doing some health checks.
google app engine takes care of everything for me
I have a simple setup for my pet projects:
1. Push code in github
2. Run fab deploy (fabric)
Fabric pull the code from github, puts it in the server and restarts the services (mongo, nginx) if needed.
I took some inspiration from newblur's fabfile.py: https://github.com/samuelclay/NewsBlur/blob/master/fabfile.p...
Fabric pull the code from github, puts it in the server and restarts the services (mongo, nginx) if needed.
I took some inspiration from newblur's fabfile.py: https://github.com/samuelclay/NewsBlur/blob/master/fabfile.p...
That's a pretty big fabfile! Do you do anything special with your DB as you switch over?
After all 40,000 unit tests have passed, sync that version to prod with ssh tunnel. Rsync to new directory on all target machines in a rsync tree. Switch to new version by moving a symlink. Verify new version by looking at metrics -- if something is off, automatically switch back. Repeat up to 50 times a day ;-)
Have you had to deal with users with sessions across multiple versions?
All the time! We use PHP, so each request is a blank slate -- persistent state is all in mysql, redis and memcached.
DB schemas are pushed/applied before the code that uses them.
Also if it wasn't clear: all those steps are automated, other than running the "I want trunk on prod now" script. We really should make that a post-test hook. Any year now ;-)
We have a staging server which is a carbon copy of the production server, and is auto-updated via post-commit hook (SVN). Everybody tests on that server until no more issues are found, and then it is pushed manually to production.
If the push involves db schema changes, we'll take the production offline for the duration of the push, showing a "Be back shortly" page.
If the push involves db schema changes, we'll take the production offline for the duration of the push, showing a "Be back shortly" page.
The shop I just moved to has the usual roll-your-own mess, but the shop I just left did it right: "yum update". Making RPMs isn't hard, and it ensures appropriate versions of all dependencies are there (even stuff like syslog-ng configs), and their tiny overworked sysadmin team didn't have to know or care which language they're implemented in, or whether there's anything smuggled onto each box behind their backs, or how to bring a freshly-imaged box into production. They ran a small script to fake a health check failure on a few servers at a time to do it without load, because they didn't want to reserve the footprint to run two versions of an app server in parallel on each box.
For unscatter.com its simply git pull then supervisorctl restart all, but that app isn't anything more than a some tornado app servers.
Automate every step possible.
Deploy? I just edit it live, I mean what could go wrong?
We've been using Beanstalk (http://www.beanstalkapp.com) for a few months now to collaborate more effectively, and thus far pretty impressed. Great system, and they've consistently added new features often.
While I'm no longer a member of the wonderful team at Beanstalk, I can tell you for certain that this comment is appreciated.
Happy to answer any questions about Beanstalk Deployments which is my personal favorite part of the system: http://beanstalkapp.com/features/deployments
Happy to answer any questions about Beanstalk Deployments which is my personal favorite part of the system: http://beanstalkapp.com/features/deployments