0

I wonder how people deal with gradually rolling out features and versions in a production evironment. the scenario is where you have two versions of tested code one already in production and one to be rolled out, these are the common issues..

  • different versions of code within same rails app.
  • different versions of rails app during rollout to users.
  • different database structures between version
  • moving data across new databases and servers.

here are some ideas for the above for discussion

  • if statements with constant, version numbers in M,V,C names
  • load balance to different app servers (how to make sticky?) , RVM
  • have old and new fields in tables as temporary, or migrate records to new tables or
    databases.
  • no easy way to move data between servers.

1 Answers1

0

It sounds like you need a good branching and merging strategy. If you're using something like Git or SVN, then anything on master or trunk, respectively, should be production-ready quality. If you're running into situations where the AbcController is good and ready to go, but XyzController is flaky, then the XyzController probably needs more testing and shouldn't be in master yet.

Migrations in rails also follow this policy, which lead to your data structure. If you think that you're ready for production, then there should't be significant changes to your database. Maybe you need to add a column or feature, but you should be well past wholesale database refactorings.

Finally, uploading/updating data is a pain in any migration situation. In my experience, it involves writing SQL scripts to perform the moves, or update the database for some new feature. Those SQL scripts should also be under your source control. Rails can make this easier, by writing your migration scripts in the migration file itself. Depending on your exact situation, this can work.

Jarrett Meyer
  • 19,333
  • 6
  • 58
  • 52
  • 1
    the scenario is where you have two versions of tested code one already in production and one to be rolled out, however, you gradually roll out the new version meaning at some point your going to have users on different versions of code, possibly with different databases requirements. –  May 19 '11 at 10:35
  • I don't think this answers the question. Rolling out framework updates, features, etc to ten percent of your user base is ideal for minimizing risk. – Garrett Lancaster Aug 28 '13 at 01:22