I would suggest creating a flag in your codebase that controls whether
the feature is exposed for use or not. Deploy the new code, run the
migrations, and do your testing. If all looks good flip the config
switch and now your users can use the feature. If you do this
intelligently you can add support so that some users can use it ie
your test users or beta users before you broaden it to a larger
audience. My team has used this technique when we wanted to expose a
feature timed with some other event like a partnership announcement.
It allowed us to deploy and test and not have to do a deploy at a
ridiculous time. The feature just began working at it's appointed time.
On Jul 14, 2010, at 12:38 PM, gwgeller <[email protected]>
wrote:
Hello,
I have situations where it would be nice to have the tables setup
in the production db before actually deploying the code that uses
them. For instance I have an automated job that accesses the
production table. I can't test this job until I deploy the code and do
the migrations. At that point everything is live. I've tested
everything in my test environment, but I'd like to test my production
environment too. So my question is how to just deploy migrations so I
can run them. Then deploy the code. I'm thinking there is a way to
deploy each migration individually but that can take awhile if there
are many migrations. Anyway just wondering what everyone thinks.
Thanks,
GG
--
* You received this message because you are subscribed to the Google
Groups "Capistrano" group.
* To post to this group, send email to [email protected]
* To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
--
* You received this message because you are subscribed to the Google Groups
"Capistrano" group.
* To post to this group, send email to [email protected]
* To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/capistrano?hl=en
