

Ask HN: how do you stage/push your code? - azarias

I was wondering if you could share some best practices for staging and pushing code. Thank you.
======
ericclemmons
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 :)

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

------
zengr
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...](https://github.com/samuelclay/NewsBlur/blob/master/fabfile.py)

~~~
azarias
That's a pretty big fabfile! Do you do anything special with your DB as you
switch over?

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

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

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

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

------
jwatte
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
;-)

~~~
azarias
Have you had to deal with users with sessions across multiple versions?

~~~
jwatte
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 ;-)

------
jrussbowman
For unscatter.com its simply git pull then supervisorctl restart all, but that
app isn't anything more than a some tornado app servers.

------
TYPE_FASTER
Automate every step possible.

------
tiedup
google app engine takes care of everything for me

------
indiecore
Deploy? I just edit it live, I mean what could go wrong?

