Hacker News new | comments | show | ask | jobs | submit login

Sometimes it absolutely can't be avoided, but usually the last version and the next version can be coded to work off of either schema.

As for deploying to a segment of users put a "version" field in the user and then gate features based on the version. If you name your versions or use a unique numbering system it should be fairly easy to remove the old gating.

Yes, none of these things are foolproof but then again your existing system probably isn't either. The more you deploy the better you get at it and the more automated it becomes. Force the issue by forcing a deploy everyday to begin with, then ramp up to twice a day, etc. After a month or two you'll learn solutions to almost all your deployment problems and there will be a well-known solution in the organization for solving the problem whether it be gating features or schema migrations.

I cringe at the thought of putting versioning gates all over my code, but maybe that's the easiest solution.

What about having two code bases on your production server and having your web server (nginx) route the traffic accordingly? 85% goes to the current code base and 15% goes to the new one?

If that's possible it would seem pretty easy.

I think that makes it less testable but would probably work, it's probably a good stop gap as long as you don't want to test more than one "feature" at a time.

Gating would probably work better in the long term as you get more devs and users, and need to do things like A/B/C testing.

Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact