We had a similar problem recently and we split the content (in your case
public) into its own application. So in the app deployment, public is
symlinked to /content/current. Then, you can deploy code and content
separately on their own schedules.
So, our deployment looks like:
/app/current/public -> /content/current
/app/current/models
/app/current/views/
...
/content/current/all_of_your_public_stuff
Then, we made separate cap recipes (similar to multistage) so we could
deploy each application on its own:
% cap app deploy
% cap content deploy
The app deploy has an after update_code tasks which does the symlink.
Something like:
after :'deploy:update_code' do
run "rm -rf #{release_path}/public"
run "ln -s "#{deploy_to}/../content/current" "#{release_path}/public"
end
Now, you can deploy the content on its own, and since the symlink points
at current, it will always point at the newest release of content.
Thanks,
Paul Gross
http://www.pgrs.net
Peter Booth wrote:
> Thanks for the suggestion. It works exactly as advertized and the
> cache strategy is faster
> than the export was, even without considering this.
>
> The suggestion raised another question, about how to best make use of
> Capistranos features:
>
> 1) I have an application that I want to deploy frequently to staging
> areas, but I want to deploy the public directory
> as part of a cold deploy and, after that, infrequently.
> 2) I can redeploy another revision of the app without a public
> directory, but then want to link to the "static" public directory.
> This suggests that the static /public should be in /shared, with a
> symlink to it that gets created on each deploy
> All sounds fine - but how does it get from svn to /shared in the first
> place?
>
> 1. I could check it out locally and use put
> 2. I could redefine the application base, deploy the "public"
> application, move it to the shared directory.
> 3. I could deploy the entire application (with public) then move the
> public directory to shared and create the link
>
> All of these sound ugly but 3 sounds least ugly
>
> Is there a nicer way?
>
> Peter
>
>
> On Nov 2, 2008, at 6:53 PM, Lee Hambley wrote:
>
>> Hi Peter,
>>
>> I'm going to skip to the last question you asked, and answer it with
>> a couple of hints.. firstly - you can (should?) be using the
>> remote_cache deploy strategy
>> <http://wiki.capify.org/index.php?title=Understanding_deployment_strategies#Deploy_Strategy_:remote_cache>
>>
>> - and you can benefit from it's :copy_exclude variable, which
>> excludes an array of items you define from being copied from the
>> cache to the release directory.
>>
>> - Please let me know if this doesn't help - and we'll pick up the
>> question again on Monday.
>>
>> Lee Hambley
>>
>> 2008/11/2 Peter Booth <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>>
>>
>>
>> Hello,
>>
>> I am using the multistage feature in capistrano-ext to deploy four
>> application to six or seven stages. I use a standardized directory
>> structure for all applications and use conditional logic in
>> deploy.rb
>> and the stage specific files in /deploy to ensure app-specific
>> behavior. I'd like to extend this to also use Capistrano to deploy
>> nginx configuration files and static data that is currently stored
>> within [application]/public
>>
>> Does anyone have experience of doing such a thing, ideally in a
>> fashion where application-stage-host mappings are centralized so they
>> can easily be viewed?
>>
>> Has anyone sucessfully deployed an application excluding a svn
>> subdirectory?
>> I have static files that are much larger than the rest of my
>> application and I would like to avoid having five minute deploys.
>>
>> Peter
>>
>>
>>
>>
>>
>>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
